WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
76607
event.preventedDefault is not reset after an event is dispatched
https://bugs.webkit.org/show_bug.cgi?id=76607
Summary
event.preventedDefault is not reset after an event is dispatched
Pablo Flouret
Reported
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. ]]
Attachments
patch
(15.70 KB, patch)
2012-01-18 23:47 PST
,
Pablo Flouret
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Pablo Flouret
Comment 1
2012-01-18 23:47:53 PST
Created
attachment 123081
[details]
patch
Alexey Proskuryakov
Comment 2
2012-01-19 12:18:49 PST
Does the new behavior match other browsers, or only the spec?
Pablo Flouret
Comment 3
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.
Alexey Proskuryakov
Comment 4
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?
Pablo Flouret
Comment 5
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.
Ryosuke Niwa
Comment 6
2012-01-30 12:14:09 PST
Comment on
attachment 123081
[details]
patch 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.
Ryosuke Niwa
Comment 7
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
Ehsan Akhgari [:ehsan]
Comment 8
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
Ryosuke Niwa
Comment 9
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.
Pablo Flouret
Comment 10
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.
Pablo Flouret
Comment 11
2012-04-13 17:34:28 PDT
Filed a new patch at
bug 83964
with what the spec actually says now. This one should probably be closed as invalid.
Ryosuke Niwa
Comment 12
2012-04-22 22:11:19 PDT
Comment on
attachment 123081
[details]
patch The spec has been changed NOT to reset these changes when re-dispatching events.
Ryosuke Niwa
Comment 13
2012-04-22 22:12:12 PDT
Won't fix since this behavior is no longer mandated by the spec, and may pose backward compatibility issues.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug