Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 04/24/2012 09:43 PM, Travis Leithead wrote: Based on my reading of DOM4, initEvent makes it possible to transform a trusted event into a non-trusted event and dispatch it. Is that intentional? AFAIK, yes It is only currently supported in Firefox and Opera. In IE, Chrome and Safari, the initEvent call is ignored in this scenario. After the initEvent call is ignored, Chrome will allow you to dispatch the event (unchanged), IE will not (per the prose currently in DOM3 Events). Note, chrome doesn't report the isTrusted property, so I can't tell if initEvent would have set that flag to false (hope so)! I'm trying to rationalize the behavior between DOM3 and DOM4. DOM3 Events was pretty clear that you can't dispatch an event that wasn't created with createEvent. Sounds like a bug. That wasn't the intention when isTrusted was added. Pretty simple. That's contrary to DOM4 at the moment (which allows it as long as it's been initialized); I wonder if there needs to be another check to prevent re-dispatching a trusted event?. Is there a specific reason for the current behavior? DOM3 Events is not very clear about initEvent at the moment. Should it be allowed to convert a trusted event to a non-trusted event? Yes. It should be possible to re-dispatch events. But if a script running on a web page dispatches event, the event must become untrusted. -Olli Seems like trouble. Given that IE9 and Chrome/Safari don't allow it, it won't be a compatibility issue to disallow it. Let's come to an agreement on this so that the two specs can be harmonious on this point. -Travis
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On Tue, Apr 24, 2012 at 2:23 PM, Olli Pettay olli.pet...@helsinki.fiwrote: Yes. It should be possible to re-dispatch events. But if a script running on a web page dispatches event, the event must become untrusted. What's the point of isTrusted, anyway? You have to trust other scripts running in the same page anyway. Does it come into play with cross-origin iframes or something? -- Glenn Maynard
RE: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). From: Glenn Maynard [mailto:gl...@zewt.org] Sent: Tuesday, April 24, 2012 12:38 PM To: o...@pettay.fi Cc: Travis Leithead; public-weba...@w3c.org; Anne van Kesteren (ann...@opera.com); Jacob Rossi Subject: Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent On Tue, Apr 24, 2012 at 2:23 PM, Olli Pettay olli.pet...@helsinki.fimailto:olli.pet...@helsinki.fi wrote: Yes. It should be possible to re-dispatch events. But if a script running on a web page dispatches event, the event must become untrusted. What's the point of isTrusted, anyway? You have to trust other scripts running in the same page anyway. Does it come into play with cross-origin iframes or something? -- Glenn Maynard
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On Tue, Apr 24, 2012 at 2:54 PM, Travis Leithead travis.leith...@microsoft.com wrote: Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). I know what it does; I'm asking what its purpose is. When is this useful? (It's not actually useful, and it only exists for web-compatibility is a valid answer, of course.) -- Glenn Maynard
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 9:54 PM, Travis Leithead travis.leith...@microsoft.com wrote: Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). From: Glenn Maynard [mailto:gl...@zewt.org] What's the point of isTrusted, anyway? You have to trust other scripts running in the same page anyway. Does it come into play with cross-origin iframes or something? See http://www.w3.org/TR/DOM-Level-3-Events/#events-event-type-isTrusted --tobie
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 10:00 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 24, 2012 at 2:54 PM, Travis Leithead travis.leith...@microsoft.com wrote: Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). I know what it does; I'm asking what its purpose is. When is this useful? Are you asking about the purpose of exposing the property or the purpose of trusted events? The latter's obvious: prevent visited content from triggering actions the UA wants to allow only after a user action. The former I'm not sure. --tobie
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On Tue, Apr 24, 2012 at 3:06 PM, Tobie Langel to...@fb.com wrote:
Are you asking about the purpose of exposing the property or the purpose
of trusted events?
I'm asking about the property. The flag underneath it exists only to
implement the property.
The latter's obvious: prevent visited content from triggering actions the
UA wants to allow only after a user action. The former I'm not sure.
This is a common misconception of how events work. If you're a browser,
default events do not--except for one or two web-compat exceptions--look
like this:
browse_button.addEventListener(click, function(e) { if(e.isTrusted)
openFilePicker(); }, false);
browse_button.dispatchEvent(clickEvent);
Rather, they look like this:
if(browse_button.dispatchEvent(clickEvent))
openFilePicker();
The default action--openFilePicker()--is not part of the event dispatch
process; it's part of the caller of the dispatch. You don't need a flag to
tell you that you dispatched the event. (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.)
(The main exception is the click event, which does activate the element
when a synthetic event is dispatched. This is a historical mistake, not
the norm. I don't believe that needs this flag, either, but I'll hold off
explaining why unless somebody asks.)
--
Glenn Maynard
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
(Sorry, forgot to merge drafts.) On Tue, Apr 24, 2012 at 3:02 PM, Tobie Langel to...@fb.com wrote: See http://www.w3.org/TR/DOM-Level-3-Events/#events-event-type-isTrusted Please don't link people to TR specs; that text is almost a year out of date, which invites pain and confusion. Always use editor's drafts: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html -- Glenn Maynard
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On Tue, 24 Apr 2012 22:00:24 +0200, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 24, 2012 at 2:54 PM, Travis Leithead travis.leith...@microsoft.com wrote: Glenn, isTrusted is the indicator that helps the web developer distinguish between an event fired by the UA, or one fired by JavaScript (e.g., dispatchEvent). I know what it does; I'm asking what its purpose is. When is this useful? FWIW, I too am interested in this. I included it in DOM4 because DOM Level 3 Events had it and I aimed for feature parity. (Also, www-dom is actually the DOM mailing list, but I guess it does not matter much...) -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 4:34 PM, Glenn Maynard wrote:
This is a common misconception of how events work. If you're a browser,
default events do not--except for one or two web-compat exceptions--look
like this:
browse_button.addEventListener(click, function(e) { if(e.isTrusted)
openFilePicker(); }, false);
browse_button.dispatchEvent(clickEvent);
Rather, they look like this:
if(browse_button.dispatchEvent(clickEvent))
openFilePicker();
Actually, no. The way events work, at least in Gecko, is more like this
(conceptually; the actual implementation is somewhat different):
browse_button.addEventListenerInSystemEventGroup(click,
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. The dispatch code then looks like this:
someNode.dispatchEvent(clickEvent);
and has no idea whether it's going to a browse_button or to a span
which has an a href on the ancestor chain.
The default action--openFilePicker()--is not part of the event
dispatch process; it's part of the caller of the dispatch.
That's a convenient spec fiction, but actually hard to implement that
way; it requires some way for the event dispatch process to communicate
to the caller of the dispatch the set of desired default actions. See
the hoops that the spec has to jump through to deal with nested
activation behavior, for example
Oh, and that's before we get into default actions implemented by extensions.
(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.
(The main exception is the click event
And a rather big exception it is!
-Boris
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 11:04 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/24/12 5:02 PM, Boris Zbarsky wrote: Oh, and that's before we get into default actions implemented by extensions. And one more thing: extensions _definitely_ want to know whether events are trusted or not. This doesn't necessitate a web-exposed API, obviously; the property could only be visible in extension code. But it does necessitate the internal flag. So is it exposed to web content to fulfill particular use-cases? --tobie
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 5:08 PM, Tobie Langel wrote: On 4/24/12 11:04 PM, Boris Zbarskybzbar...@mit.edu wrote: On 4/24/12 5:02 PM, Boris Zbarsky wrote: Oh, and that's before we get into default actions implemented by extensions. And one more thing: extensions _definitely_ want to know whether events are trusted or not. This doesn't necessitate a web-exposed API, obviously; the property could only be visible in extension code. But it does necessitate the internal flag. So is it exposed to web content to fulfill particular use-cases? Gecko initially exposed it because it was easier to do so than to only expose it to extensions but hide it from web content, I believe (or more precisely the latter was not really possible in Gecko at the time; it would be quite possible now). I wasn't involved in the discussion about exposing it in the spec, so no idea what the precise reasons there were. Web content _can_ have the same use cases as browser extensions, but Glenn's point about web content having to trust other stuff in the same frame is of course true. At least until we start having some web content with elevated privileges (see e.g. the direction Boot2Gecko is going in) which will require something like this exposed again. -Boris
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On Tue, 24 Apr 2012 23:02:22 +0200, Boris Zbarsky bzbar...@mit.edu wrote: (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. Last time I discussed this with Jonas Sicking he agreed that Gecko could change some things here and he also agreed with the model put forward. If the model is wrong we should fix it of course. It does indeed not apply universally and as far as I know HTML does cater for those exceptions in various ways. It would be interesting to know where it does not. I'm not sure how extensions are relevant here. If you allow them to do complex things then of course they will be complex to implement, but there is not much we can do about that. -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 4/24/12 5:16 PM, Anne van Kesteren wrote: On Tue, 24 Apr 2012 23:02:22 +0200, Boris Zbarsky bzbar...@mit.edu wrote: (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. Last time I discussed this with Jonas Sicking he agreed that Gecko could change some things here and he also agreed with the model put forward. If the model is wrong we should fix it of course. It's a conceptual model. I'm just saying that actual implementations behave differently on the inside; I don't think the difference is black-box distinguishable from a typical web page. I'm not sure how extensions are relevant here. Glenn asked why events need internal state that indicates whether they're trusted. Extensions are one of the reasons. If you allow them to do complex things then of course they will be complex to implement, but there is not much we can do about that. Sure there is, where we == browser vendors. We can expose APIs to extensions to make them easier to implement. APIs that expose things like the trusted state of events. -Boris
RE: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16847 to track getting DOM3 updated on this point. Thanks for the info. BTW: Olli, your email isn't recognized in the Bug DB's CC list. Is there one that will work? -Original Message- From: Olli Pettay [mailto:olli.pet...@helsinki.fi] Sent: Tuesday, April 24, 2012 12:23 PM To: Travis Leithead Cc: public-weba...@w3c.org; Anne van Kesteren (ann...@opera.com); Jacob Rossi Subject: Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent On 04/24/2012 09:43 PM, Travis Leithead wrote: Based on my reading of DOM4, initEvent makes it possible to transform a trusted event into a non-trusted event and dispatch it. Is that intentional? AFAIK, yes It is only currently supported in Firefox and Opera. In IE, Chrome and Safari, the initEvent call is ignored in this scenario. After the initEvent call is ignored, Chrome will allow you to dispatch the event (unchanged), IE will not (per the prose currently in DOM3 Events). Note, chrome doesn't report the isTrusted property, so I can't tell if initEvent would have set that flag to false (hope so)! I'm trying to rationalize the behavior between DOM3 and DOM4. DOM3 Events was pretty clear that you can't dispatch an event that wasn't created with createEvent. Sounds like a bug. That wasn't the intention when isTrusted was added. Pretty simple. That's contrary to DOM4 at the moment (which allows it as long as it's been initialized); I wonder if there needs to be another check to prevent re-dispatching a trusted event?. Is there a specific reason for the current behavior? DOM3 Events is not very clear about initEvent at the moment. Should it be allowed to convert a trusted event to a non-trusted event? Yes. It should be possible to re-dispatch events. But if a script running on a web page dispatches event, the event must become untrusted. -Olli Seems like trouble. Given that IE9 and Chrome/Safari don't allow it, it won't be a compatibility issue to disallow it. Let's come to an agreement on this so that the two specs can be harmonious on this point. -Travis
Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On 04/25/2012 12:16 AM, Anne van Kesteren wrote: On Tue, 24 Apr 2012 23:02:22 +0200, Boris Zbarsky bzbar...@mit.edu wrote: (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. Last time I discussed this with Jonas Sicking he agreed that Gecko could change some things here and he also agreed with the model put forward. It is not only about Gecko, but all the browser engines, at least last time I tested it. If the model is wrong we should fix it of course. It does indeed not apply universally and as far as I know HTML does cater for those exceptions in various ways. It would be interesting to know where it does not. I'm not sure how extensions are relevant here. If you allow them to do complex things then of course they will be complex to implement, but there is not much we can do about that.
