16336 2012-03-12 21:09:03 +0000 defaultPrevented and preventDefault() conflict 2012-05-05 19:08:53 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - DOM3 Events unspecified PC Windows NT RESOLVED FIXED http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0067.html LC, needsReview P2 normal --- 1 travil travil annevk mike Ms2ger ojan www-dom public-webapps-bugzilla oldest_to_newest 65398 0 travil 2012-03-12 21:09:03 +0000 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.) 65399 1 travil 2012-03-12 21:10:23 +0000 [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> <script> var foo = document.getElementById('foo'); foo.addEventListener('click', function(e) {e.preventDefault();alert(e.defaultPrevented)}); foo.addEventListener('blur', function(e) {e.preventDefault();alert(e.defaultPrevented)}); </script> This approach makes more sense to me since it gives more information to web developers. Ojan 67191 2 travil 2012-04-30 22:24:09 +0000 I agree. I'll update the spec text so that defaultPrevented reflects the actual internal state of the event. 67199 3 travil 2012-04-30 23:10:43 +0000 Fixed in latest update. 67350 4 Ms2ger 2012-05-05 19:08:53 +0000 Added a test: http://dvcs.w3.org/hg/webapps/rev/f7745b53fc02