Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent

On Tue, Apr 24, 2012 at 4:02 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> Actually, no.  The way events work, at least in Gecko, is more like this
> (conceptually; the actual implementation is somewhat different):
>
>  browse_button.**addEventListenerInSystemEventG**roup("click",
>

(Let's avoid "click" in examples, since it's the weird exception.  Sorry--I
did it first.)

   function(e) {
>      if (e.isTrusted && !e.defaultPrevented) {
>        e.preventDefault();
>        openFilePicker();
>      }
>    }, false);
>
> This is needed because there might be multiple things that might wish to
> perform a default action based on a click (in particular, every single
> thing the click bubbles through), and the code that actually dispatches a
> click can't possibly have an idea of the full set of default actions
> involved.


This is just an implementation detail, though; it's the visible behavior
and how the DOM event model appears to users that I meant to refer to.

 (DOM3's language
>> about "default actions" confuses this; I suggest reading DOM4's event
>> section to get a good picture of how this actually works.)
>>
>
> Or rather how the DOM4 editor is choosing to conceptualize it, which may
> not have much bearing on how it actually works in actual browsers.


It's much closer to how the DOM event model works--from the perspective of
user-visible behavior--than how it's described in DOM3, in my opinion.  It
also seems much less likely to result in new APIs misusing DOM Events.  (I
recall that Clipboard API almost introduced another exceptional
"click"-like event recently...)


>  (The main exception is the "click" event
>>
>
> And a rather big exception it is!


Definitely, but it arguably doesn't need isTrusted either.  Although some
elements don't activate on non-trusted clicks (such as <input type=file>),
it doesn't need isTrusted; the "in response to a user interaction" metric
that Firefox uses for HTMLInputElement.click (eg. allowing it in response
to a keypress) is all that really needs, I think.

That aside, if that "disallowed-click-events" case--an exception within an
exception--is still a reason to need the internal trusted flag from the
perspective of specs as they're written today, then that's good to know, at
least.

It sounds like web compat is the only likely reason for exposing this to
scripts, though.

-- 
Glenn Maynard