Bug 16336 - defaultPrevented and preventDefault() conflict
Summary: defaultPrevented and preventDefault() conflict
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
URL: http://lists.w3.org/Archives/Public/w...
Keywords: LC, needsReview
Depends on:
Reported: 2012-03-12 21:09 UTC by Travis Leithead [MSFT]
Modified: 2012-05-05 19:08 UTC (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Travis Leithead [MSFT] 2012-03-12 21:09:03 UTC
defaultPrevented says it reflects whether preventDefault() has been  
invoked for the event whereas preventDefault() says it only has an effect  
if the event is in fact cancelable. I think this has led to different  
implementations of these features in e.g. Opera and Gecko.

In DOM Core defaultPrevented can only be true for cancelable events. (This  
is another reason why I changed initEvent() to also reset the "canceled  
flag" so that if you change an event from being cancelable to  
non-cancelable everything still makes sense.)
Comment 1 Travis Leithead [MSFT] 2012-03-12 21:10:23 UTC
[see http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0077.html]

This seems to match the WebKit behavior as well.

Test case I used to verify:
<input id=foo>
var foo = document.getElementById('foo');
foo.addEventListener('click', function(e)
foo.addEventListener('blur', function(e)

This approach makes more sense to me since it gives more information to web

Comment 2 Travis Leithead [MSFT] 2012-04-30 22:24:09 UTC
I agree. I'll update the spec text so that defaultPrevented reflects the actual internal state of the event.
Comment 3 Travis Leithead [MSFT] 2012-04-30 23:10:43 UTC
Fixed in latest update.
Comment 4 Ms2ger 2012-05-05 19:08:53 UTC
Added a test: http://dvcs.w3.org/hg/webapps/rev/f7745b53fc02