- 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