- From: <bugzilla@jessica.w3.org>
- Date: Thu, 19 Apr 2012 18:50:25 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16332 --- Comment #5 from Travis Leithead [MSFT] <travil@microsoft.com> 2012-04-19 18:50:21 UTC --- (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. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Thursday, 19 April 2012 18:50:28 UTC