This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.)
[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
I agree. I'll update the spec text so that defaultPrevented reflects the actual internal state of the event.
Fixed in latest update.
Added a test: http://dvcs.w3.org/hg/webapps/rev/f7745b53fc02