16332 2012-03-12 20:41:32 +0000 stop propagation and canceled flags 2012-04-20 00:31:24 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - DOM3 Events unspecified PC Windows NT RESOLVED FIXED http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0054.html LC, needsReview P2 normal --- 1 travil travil annevk mike www-dom public-webapps-bugzilla oldest_to_newest 65384 0 travil 2012-03-12 20:41:32 +0000 PORTING separate issues from TRACKER, issue 186... [Copied from http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0054.html] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-flow says "As the final step of the event dispatch, for reasons of backwards compatibility, the implementation must reset the event object's internal-propagation and default-action-prevention states." As far as I can tell this is not implemented this way. Propagation is not reset in either Opera or WebKit (it is in Gecko). Load the following in http://software.hixie.ch/utilities/js/live-dom-viewer/ to test: <!DOCTYPE html> ...<script> var e = document.createEvent("Event") e.initEvent("test", false, true) document.addEventListener("test", function() { w("invoked") }, false) e.stopPropagation(); w("d1: " + document.dispatchEvent(e)) w("d2: " + document.dispatchEvent(e)) </script> Similarly, in Opera, WebKit or Gecko the canceled flag does not appear to be reset. Load the following in the same viewer to test: <!DOCTYPE html> ...<script> function callback(ev) { if("defaultPrevented" in ev) w("ev: " + ev.defaultPrevented) else w("ev: " + ev.getPreventDefault()) } var e = document.createEvent("Event") e.initEvent("test", false, true) document.addEventListener("test", callback, false) e.preventDefault(); w("d1: " + document.dispatchEvent(e)) w("d2: " + document.dispatchEvent(e)) </script> So it appears that there is no backwards compatibility issue here. Having said that, something to reset these flags might be nice so event objects can be reused. Or do we always want people to create new event objects? Maybe invoking initEvent() should reset these flags? As invoking initEvent() can also change the nature of it being cancelable. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/ 65388 1 travil 2012-03-12 20:48:14 +0000 [see http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0063.html] Tue, 01 Mar 2011 21:01:04 +0100, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: > * Anne van Kesteren wrote: >> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-flow >> says "As the final step of the event dispatch, for reasons of backwards >> compatibility, the implementation must reset the event object's >> internal-propagation and default-action-prevention states." > > This is the result of issues 20 and 35 in the former WebAPI Working > Group where you will find test cases and data and opinions on this. http://www.w3.org/2006/webapi/track/issues/35 has a public view and does seem to reach a similar conclusion. Namely that behavior is not very much the same and we can probably do "whatever". It does not explain, as far as I can tell, "for reasons of backwards compatibility". I have also read through http://www.w3.org/2005/06/tracker/webapi/issues/20 and http://www.w3.org/2005/06/tracker/webapi/issues/35 and the few emails associated with them. They also seem to reach similar conclusions. > I do note that in order to adequately test this you would also have > to check, say, implementation-generated events versus synthesized > ones, and modifying these states from within handlers rather than > before dispatching them the first time. Feel free to be inspired by > the member-only test code I submitted for these issues if they are > useful. Both Glenn and I have played around with that as well, getting much the same result as you back then. >> As far as I can tell this is not implemented this way. Propagation is >> not reset in either Opera or WebKit (it is in Gecko). > >> So it appears that there is no backwards compatibility issue here. > > Clearly if Firefox behaves in a certain way here then doing some- > thing else might break deployed code that works today in Firefox, > so it would seem there is indeed a compatibility issue there. Between browsers, yes. But "backwards compatibility" is generally used as a term meaning the "wider web relies on this behavior" which I do not think is established here, especially since Gecko does not do this for the "canceled flag". The "canceled flag" is the most problematic I think. I would prefer it if defaultPrevented remains to make sense after the event is dispatched. But given that most browsers do not reset these flags it seems we can get away with only unsetting them when initEvent() is invoked. >> Having said that, something to reset these flags might be nice so event >> objects can be reused. Or do we always want people to create new event >> objects? Maybe invoking initEvent() should reset these flags? As >> invoking initEvent() can also change the nature of it being cancelable. > > I would regard it as a bad practise to use the same event object > multiple times; semantically event objects are event instances, > and an instance of an event is unique. And you would be relying on > hidden state, which is unreliable, as you can see here. Do note > that these questions have also been discussed in the issues above, > at least as I recall them. Unsetting these flags would not just be for re-dispatching, but would also allow you to reconfigure it before dispatching has taken place at all. I agree re-dispatching is dubious, but we have to define how it works. I think based on the information in the older issues that we should change the model so that these three flags are only ever reset for initEvent() and otherwise never. I will change DOM Core to match that. I hope that works for everyone. -- Anne van Kesteren http://annevankesteren.nl/ 66002 2 travil 2012-03-24 00:12:24 +0000 (In reply to comment #0) > Load the following in > http://software.hixie.ch/utilities/js/live-dom-viewer/ to test: > > <!DOCTYPE html> > ...<script> > var e = document.createEvent("Event") > e.initEvent("test", false, true) > document.addEventListener("test", function() { w("invoked") }, false) > e.stopPropagation(); > w("d1: " + document.dispatchEvent(e)) > w("d2: " + document.dispatchEvent(e)) > </script> Consistent in all browsrs but Firefox... > > Similarly, in Opera, WebKit or Gecko the canceled flag does not appear to > be reset. Load the following in the same viewer to test: > > <!DOCTYPE html> > ...<script> > function callback(ev) { > if("defaultPrevented" in ev) > w("ev: " + ev.defaultPrevented) > else > w("ev: " + ev.getPreventDefault()) > } > var e = document.createEvent("Event") > e.initEvent("test", false, true) > document.addEventListener("test", callback, false) > e.preventDefault(); > w("d1: " + document.dispatchEvent(e)) > w("d2: " + document.dispatchEvent(e)) > </script> IE has true/false values flipped, all other browsers are the same. 66860 3 1120 travil 2012-04-19 18:39:30 +0000 Created attachment 1120 Tests re-dispatching a trusted event and whether the stop-propagation flags are reset 66861 4 1121 travil 2012-04-19 18:49:53 +0000 Created attachment 1121 Tests re-dispatching a trusted event and whether the default-action-prevention state flags are reset 66862 5 travil 2012-04-19 18:50:21 +0000 (In reply to comment #2) > (In reply to comment #0) > > > Load the following in > > http://software.hixie.ch/utilities/js/live-dom-viewer/ to test: > > > > <!DOCTYPE html> > > ...<script> > > var e = document.createEvent("Event") > > e.initEvent("test", false, true) > > document.addEventListener("test", function() { w("invoked") }, false) > > e.stopPropagation(); > > w("d1: " + document.dispatchEvent(e)) > > w("d2: " + document.dispatchEvent(e)) > > </script> > > Consistent in all browsrs but Firefox... Meaning that in all browsers but Firefox, the object's "internal-propagation" flag is _not_ reset between dispatches, contrary to what DOM3 Events states. It also means that stopPropagation() can take effect before the event has been initially dispatched. Note: When re-dispatching trusted events (see attached "TestingTrustedDispatchAndStopPropagation") I see the following results: IE: (untestable) since it throws NotSupportedError as required by DOM3 Events under "dispatchEvent" (the Event was not created using document.createEvent). Chrome/Safari/Opera: dispatches the event, and the state was not reset, just like the un-trusted scenario. Firefox: dispatches the event, and the state is reset (just as it behaved before). > > Similarly, in Opera, WebKit or Gecko the canceled flag does not appear to > > be reset. Load the following in the same viewer to test: > > > > <!DOCTYPE html> > > ...<script> > > function callback(ev) { > > if("defaultPrevented" in ev) > > w("ev: " + ev.defaultPrevented) > > else > > w("ev: " + ev.getPreventDefault()) > > } > > var e = document.createEvent("Event") > > e.initEvent("test", false, true) > > document.addEventListener("test", callback, false) > > e.preventDefault(); > > w("d1: " + document.dispatchEvent(e)) > > w("d2: " + document.dispatchEvent(e)) > > </script> > > IE has true/false values flipped, all other browsers are the same. (Meaning that in all browsers the "default-action-prevention" state is _not_ reset between dispatches, contrary to what is stated by DOM3 Events. It also means that IE has a bug wherein it does not honor preventDefault() prior to dispatching an event.) [The "true" return value for dispatchEvent in IE can be partially explained by a critical reading of the prose under "Return Value" for dispatch event (** emphasis mine**): | "Indicates whether **any of the listeners which handled the event** | called Event.preventDefault(). If Event.preventDefault() was called | the returned value must be false, else it must be true." ...however, the value of defaultPrevented inside of the handler being "false" is clearly a bug without any backing from existing prose in DOM3 Events. :-)] Note: When re-dispatching trusted events (see attached "TestingTrustedDispatchAndPreventDefault") I see the following results: IE: (untestable) since it throws NotSupportedError as required by DOM3 Events under "dispatchEvent" (the Event was not created using document.createEvent). Firefox/Chrome/Safari/Opera: dispatches the event, and the state was not reset, just like the un-trusted scenario. 66863 6 travil 2012-04-19 18:56:26 +0000 Based on the result from Comment 5, DOM3 Events needs to be updated in two places for clarification: (In reply to comment #0) > says "As the final step of the event dispatch, for reasons of backwards > compatibility, the implementation must reset the event object's > internal-propagation and default-action-prevention states." > > As far as I can tell this is not implemented this way. Propagation is not > reset in either Opera or WebKit (it is in Gecko). The above spec comment needs to be removed from the event dispatch algorithm. Something to its effect should be placed in the requirements for initEvent which will be the only time that these internal state values will be reset. (In reply to comment #5) > [The "true" return value for dispatchEvent in IE can be partially explained by > a critical reading of the prose under "Return Value" for dispatch event (** > emphasis mine**): > > | "Indicates whether **any of the listeners which handled the event** > | called Event.preventDefault(). If Event.preventDefault() was called > | the returned value must be false, else it must be true." > > ...however, the value of defaultPrevented inside of the handler being "false" > is clearly a bug without any backing from existing prose in DOM3 Events. :-)] The prose under the Return Value for dispatchEvent will be tweaked to indicate that preventDefault should be honored even if the caller used preventDefault _before_ the event was dispatched (which is what implementations allow). 66871 7 annevk 2012-04-19 22:57:50 +0000 Do you know what the new text will be like relative to DOM4? The same effect? 66876 8 travil 2012-04-20 00:31:24 +0000 I've made the changes. I updated initEvent to describe the process of resetting the internal flags. This should match DOM4's behavior. 1120 2012-04-19 18:39:30 +0000 2012-04-19 18:39:30 +0000 Tests re-dispatching a trusted event and whether the stop-propagation flags are reset TestingTrustedDispatchAndStopPropagation.htm text/html 1019 travil 77u/PCFET0NUWVBFIGh0bWw+DQoNCjxodG1sIGxhbmc9ImVuIiB4bWxucz0iaHR0cDovL3d3dy53 My5vcmcvMTk5OS94aHRtbCI+DQo8aGVhZD4NCiAgICA8bWV0YSBjaGFyc2V0PSJ1dGYtOCIgLz4N CiAgICA8dGl0bGU+VGVzdGluZyBUcnVzdGVkIERpc3BhdGNoIGFuZCBTdG9wIFByb3BhZ2F0aW9u PC90aXRsZT4NCiAgICA8c3R5bGU+dGV4dGFyZWF7d2lkdGg6OTAlO2hlaWdodDo1MDBweDt9PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5Pg0KICAgIDxidXR0b24gaWQ9InByaW1hcnlUZXN0Ij5DbGlj ayBtZSB0byB0ZXN0PC9idXR0b24+DQogICAgPGRpdiBpZD0ic2Vjb25kYXJ5VGVzdCI+PC9kaXY+ DQogICAgPHRleHRhcmVhIGlkPSJvdXQiPjwvdGV4dGFyZWE+DQogICAgPHNjcmlwdD4NCiAgICAg ICAgZnVuY3Rpb24gY2FsbFN0b3BQcm9wYWdhdGlvbkFuZENhY2hlKGUpIHsgZS5zdG9wUHJvcGFn YXRpb24oKTsgZG9jdW1lbnQuY2FjaGVkRXZlbnRPYmplY3QgPSBlOyBzZXRUaW1lb3V0KHJlRGlz cGF0Y2gsIDEwMCk7IH0NCiAgICAgICAgZnVuY3Rpb24gaXNJbnZva2VkKGUpIHsgdygiaW52b2tl ZCIpOyB9DQogICAgICAgIGZ1bmN0aW9uIHJlRGlzcGF0Y2goKSB7IHcoImQyOiAiICsgZG9jdW1l bnQuZ2V0RWxlbWVudEJ5SWQoInNlY29uZGFyeVRlc3QiKS5kaXNwYXRjaEV2ZW50KGRvY3VtZW50 LmNhY2hlZEV2ZW50T2JqZWN0KSk7IH0NCiAgICAgICAgZnVuY3Rpb24gdyh4KSB7IGRvY3VtZW50 LmdldEVsZW1lbnRCeUlkKCJvdXQiKS52YWx1ZSArPSAibG9nOiAiICsgeCArICJcbiI7IH0NCiAg ICAgICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoInByaW1hcnlUZXN0IikuYWRkRXZlbnRMaXN0 ZW5lcigiY2xpY2siLCBjYWxsU3RvcFByb3BhZ2F0aW9uQW5kQ2FjaGUpOw0KICAgICAgICBkb2N1 bWVudC5nZXRFbGVtZW50QnlJZCgic2Vjb25kYXJ5VGVzdCIpLmFkZEV2ZW50TGlzdGVuZXIoImNs aWNrIiwgaXNJbnZva2VkKTsNCiAgICA8L3NjcmlwdD4NCjwvYm9keT4NCjwvaHRtbD4= 1121 2012-04-19 18:49:53 +0000 2012-04-19 18:49:53 +0000 Tests re-dispatching a trusted event and whether the default-action-prevention state flags are reset TestingTrustedDispatchAndPreventDefault.htm text/html 1104 travil 77u/PCFET0NUWVBFIGh0bWw+DQoNCjxodG1sIGxhbmc9ImVuIiB4bWxucz0iaHR0cDovL3d3dy53 My5vcmcvMTk5OS94aHRtbCI+DQo8aGVhZD4NCiAgICA8bWV0YSBjaGFyc2V0PSJ1dGYtOCIgLz4N CiAgICA8dGl0bGU+VGVzdGluZyBUcnVzdGVkIERpc3BhdGNoIGFuZCBQcmV2ZW50IERlZmF1bHQ8 L3RpdGxlPg0KICAgIDxzdHlsZT50ZXh0YXJlYXt3aWR0aDo5MCU7aGVpZ2h0OjUwMHB4O308L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQogICAgPGJ1dHRvbiBpZD0icHJpbWFyeVRlc3QiPkNsaWNr IG1lIHRvIHRlc3Q8L2J1dHRvbj4NCiAgICA8ZGl2IGlkPSJzZWNvbmRhcnlUZXN0Ij48L2Rpdj4N CiAgICA8dGV4dGFyZWEgaWQ9Im91dCI+PC90ZXh0YXJlYT4NCiAgICA8c2NyaXB0Pg0KICAgICAg ICBmdW5jdGlvbiBjYWxsU3RvcFByb3BhZ2F0aW9uQW5kQ2FjaGUoZSkgeyBlLnByZXZlbnREZWZh dWx0KCk7IGRvY3VtZW50LmNhY2hlZEV2ZW50T2JqZWN0ID0gZTsgc2V0VGltZW91dChyZURpc3Bh dGNoLCAxMDApOyB9DQogICAgICAgIGZ1bmN0aW9uIGlzSW52b2tlZChlKSB7IGlmICgiZGVmYXVs dFByZXZlbnRlZCIgaW4gZSkgdygiZXY6ICIgKyBlLmRlZmF1bHRQcmV2ZW50ZWQpOyBlbHNlIHco ImV2OiAiICsgZS5nZXRQcmV2ZW50RGVmYXVsdCgpKTsgfQ0KICAgICAgICBmdW5jdGlvbiByZURp c3BhdGNoKCkgeyB3KCJkMjogIiArIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJzZWNvbmRhcnlU ZXN0IikuZGlzcGF0Y2hFdmVudChkb2N1bWVudC5jYWNoZWRFdmVudE9iamVjdCkpOyB9DQogICAg ICAgIGZ1bmN0aW9uIHcoeCkgeyBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgib3V0IikudmFsdWUg Kz0gImxvZzogIiArIHggKyAiXG4iOyB9DQogICAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRCeUlk KCJwcmltYXJ5VGVzdCIpLmFkZEV2ZW50TGlzdGVuZXIoImNsaWNrIiwgY2FsbFN0b3BQcm9wYWdh dGlvbkFuZENhY2hlKTsNCiAgICAgICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoInNlY29uZGFy eVRlc3QiKS5hZGRFdmVudExpc3RlbmVyKCJjbGljayIsIGlzSW52b2tlZCk7DQogICAgPC9zY3Jp cHQ+DQo8L2JvZHk+DQo8L2h0bWw+