7626 – 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

This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7626 - 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

Summary: Spec says: "Note: Removing an event handler content attribute does not reset ...

Status:	CLOSED FIXED

Alias:	None

Product:	HTML WG
Classification:	Unclassified
Component:	pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version:	unspecified
Hardware:	Other other

Importance:	P3 normal
Target Milestone:	LC
Assignee:	Ian 'Hixie' Hickson
QA Contact:	HTML WG Bugzilla archive list

URL:	http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2009-09-15 10:26 UTC by contributor
Modified:	2010-10-04 14:29 UTC (History)
CC List:	6 users (show)

See Also:

Attachments

Description contributor 2009-09-15 10:26:56 UTC

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

Comment 1 Ian 'Hixie' Hickson 2009-09-29 00:39:01 UTC

My testing disagrees:
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/245

What am I missing?

Comment 2 Hallvord R. M. Steen 2009-09-29 09:57:31 UTC

I guess onload might be special due to its set-on-body-mapped-to-window weirdness. Try e.g. onclick?

Comment 3 Ian 'Hixie' Hickson 2009-09-29 10:10:58 UTC

onclick:
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/247
...still fires in at least Opera and Firefox.

Comment 4 Hallvord R. M. Steen 2009-09-29 10:12:17 UTC

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 ?

Comment 5 Hallvord R. M. Steen 2009-09-29 10:19:11 UTC

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).

Comment 6 Ian 'Hixie' Hickson 2009-09-29 10:26:23 UTC

That's a good enough reason for me!

Comment 7 contributor 2009-09-29 10:27:37 UTC

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

Comment 8 Boris Zbarsky 2009-09-29 15:52:27 UTC

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?

Comment 9 Ian 'Hixie' Hickson 2009-09-29 22:32:39 UTC

Yeah, the spec now says that all event handler content attributes, on removal, clear out there corresponding backing event handlers.

Comment 10 Maciej Stachowiak 2010-03-14 14:51:16 UTC

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.