Bug 76607 - event.preventedDefault is not reset after an event is dispatched
: event.preventedDefault is not reset after an event is dispatched
Status: RESOLVED WONTFIX
: WebKit
Event Handling
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
: http://samples.msdn.microsoft.com/iet...
:
:
:
  Show dependency treegraph
 
Reported: 2012-01-18 23:40 PST by
Modified: 2012-04-22 22:12 PST (History)


Attachments
patch (15.70 KB, patch)
2012-01-18 23:47 PST, Pablo Flouret
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-01-18 23:40:38 PST
DOM Level 3 Events sez:

[[
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 ensures that an event object may be properly dispatched multiple times while also allowing to prevent the event object's propagation or default actions prior to the event dispatch.
]]
------- Comment #1 From 2012-01-18 23:47:53 PST -------
Created an attachment (id=123081) [details]
patch
------- Comment #2 From 2012-01-19 12:18:49 PST -------
Does the new behavior match other browsers, or only the spec?
------- Comment #3 From 2012-01-19 13:29:56 PST -------
(In reply to comment #2)
> Does the new behavior match other browsers, or only the spec?

Matches IE, not firefox or opera, so yeah, might be a better idea to hold off on this one and see if anyone else is going to match the spec as well.
------- Comment #4 From 2012-01-19 13:38:07 PST -------
I wonder where the "backwards compatibility" part comes from then. Maybe you'd be willing to search working group archives, or even e-mail them?
------- Comment #5 From 2012-01-19 14:44:28 PST -------
There's some info on that here:
http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0063.html

It seems that the wording didn't just confuse me.

I'd say it's mostly an unresolved issue, at least for the dom level 3 spec, dom core says that the flags should be reset in initEvent.
------- Comment #6 From 2012-01-30 12:14:09 PST -------
(From update of attachment 123081 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=123081&action=review

> Source/WebCore/dom/EventDispatcher.cpp:393
> +    return !defaultPrevented;

We normally return defaultPrevented, instead of !defaultPrevented, so you might want to do that here.
------- Comment #7 From 2012-01-30 12:21:15 PST -------
It appears that DOM4 doesn't have that clause so it's likely that we don't need to fix this bug:
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dispatching-events
------- Comment #8 From 2012-01-30 12:28:58 PST -------
I think we can implement this in Gecko as well, as the webcompat risk seems rather low.  I filed this bug for Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=722437
------- Comment #9 From 2012-01-30 12:29:45 PST -------
smaug from Mozilla told me IE started this behavior in 9. So I'll be shocked if this had a backward compatibility issue. On the other hand, I don't think this will cause a serious compatibility with us either so I'm fine with going forward with this patch as well.
------- Comment #10 From 2012-01-30 12:47:53 PST -------
(In reply to comment #7)
> It appears that DOM4 doesn't have that clause so it's likely that we don't need to fix this bug:
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dispatching-events

It was moved to initEvent(), see step 3 here: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-event-initevent

I think the idea is to make events re-usable, i can make a new patch if we want to go that way as well.
------- Comment #11 From 2012-04-13 17:34:28 PST -------
Filed a new patch at bug 83964 with what the spec actually says now. This one should probably be closed as invalid.
------- Comment #12 From 2012-04-22 22:11:19 PST -------
(From update of attachment 123081 [details])
The spec has been changed NOT to reset these changes when re-dispatching events.
------- Comment #13 From 2012-04-22 22:12:12 PST -------
Won't fix since this behavior is no longer mandated by the spec, and may pose backward compatibility issues.