7626 2009-09-15 10:26:56 +0000 Spec says: "Note: Removing an event handler content attribute does not reset the corresponding event handler attribute.". In fact browsers will remove or "deactivate" the listener when you remove the HTML attribute. Some browsers reset it to null or undef 2010-10-04 14:29:03 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified Other other CLOSED FIXED http://www.whatwg.org/specs/web-apps/current-work/#events P3 normal LC 1 contributor ian bzbarsky hsteen ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 27171 0 contributor 2009-09-15 10:26:56 +0000 Section: http://www.whatwg.org/specs/web-apps/current-work/#events Comment: Spec says: "Note: Removing an event handler content attribute does not reset the corresponding event handler attribute.". In fact browsers will remove or "deactivate" the listener when you remove the HTML attribute. Some browsers reset it to null or undefined, some don't but Gecko/IE/WebKit agree on not firing events after removeAttribute() was called. (It's considered a bug in Opera that we differ). -- Hallvord Posted from: 213.236.208.22 27744 1 ian 2009-09-29 00:39:01 +0000 My testing disagrees: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/245 What am I missing? 27822 2 hsteen 2009-09-29 09:57:31 +0000 I guess onload might be special due to its set-on-body-mapped-to-window weirdness. Try e.g. onclick? 27826 3 ian 2009-09-29 10:10:58 +0000 onclick: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/247 ...still fires in at least Opera and Firefox. 27827 4 hsteen 2009-09-29 10:12:17 +0000 What browser did you test in btw? Seems to work as this bug claims it should work in Safari (though Safari on the computer I type this from may be a bit old). Seems I can not reopen this bug but Ian - can you do a bit more testing? What happens for you on http://software.hixie.ch/utilities/js/live-dom-viewer/saved/248 ? 27828 5 hsteen 2009-09-29 10:19:11 +0000 thanks for answering the questions before I ask them :-) Opera thinks it's a bug and intends to fix it. The reason is that we have received reports that not doing so can open up XSS holes if user input is parsed with a DOMParser and sanitised by walking the DOM and removing attributes and tags that are not whitelisted. I can not give you the source of this information because the vulnerability may still be live on some sites, but we think mirroring the listeners and the attributes as closely as legacy content will allow would be the most expected behaviour from an author point of view. I also believe that this is a relatively obscure corner case which is unlikely to cause compat problems (particularly since browsers already disagree). 27829 6 ian 2009-09-29 10:26:23 +0000 That's a good enough reason for me! 27830 7 contributor 2009-09-29 10:27:37 +0000 Checked in as WHATWG revision r4050. Check-in comment: Removing an event handler content attribute needs to clear out the event handler. http://html5.org/tools/web-apps-tracker?from=4049&to=4050 27871 8 bzbarsky 2009-09-29 15:52:27 +0000 So I'm confused. In Gecko, the <body> examples all put stuff on the window, so that's presumably what you see going on. This testcase: <!DOCTYPE html> <body> <p id="p" onclick="">click me</p> <script> var p = document.getElementById("p"); p.onclick = function() { alert('clicked'); } p.removeAttribute("onclick"); </script> doesn't show an alert when clicking on the text. So is the point that the behavior for event listeners on <body> needs to match that? 27888 9 ian 2009-09-29 22:32:39 +0000 Yeah, the spec now says that all event handler content attributes, on removal, clear out there corresponding backing event handlers. 33453 10 mjs 2010-03-14 14:51:16 +0000 This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.