13684 2011-08-05 10:10:46 +0000 Event handler attributes should reregister each time they are changed (?) 2011-10-07 21:45:16 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC Linux RESOLVED FIXED P2 normal --- 1 bugs ian annevk bzbarsky contributor ian jrossi mike Ms2ger public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 54225 0 1021 bugs 2011-08-05 10:10:46 +0000 Created attachment 1021 testcase " Event handlers therefore always run before event listeners attached using addEventListener()" is wrong. It is not what browsers (tested F, C, O) do. 54227 1 bugs 2011-08-05 10:15:18 +0000 *** Bug 13683 has been marked as a duplicate of this bug. *** 54296 2 ian 2011-08-06 06:10:30 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, 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 Status: Did Not Understand Request Change Description: no spec change Rationale: Removing the note is pointless, it's not normative. If you want the normative requirements changed, that's a different matter. What would you like the behaviour to be? 54314 3 bugs 2011-08-06 09:50:38 +0000 Event listeners are called in the order they are added to the event target. 54315 4 bugs 2011-08-06 09:51:30 +0000 I couldn't figure out what in the spec leads to "therefore always". 54347 5 bzbarsky 2011-08-07 02:19:40 +0000 > I couldn't figure out what in the spec leads to "therefore always". This bit: All event handlers on an object, whether an element or some other object, and whether set to null or to a Function object, must be registered as event listeners on the object when it is created which means ipso facto that they're registered before any other event listeners (since those can't be registered before the object is created). 54351 6 bugs 2011-08-07 08:08:09 +0000 Oh, I read that so that if elements have onfoo content attributes, they must be registered as event listeners when element is basically parsed/created. But ok, I misread that part. But anyway, that is buggy, not something browser do, and there is no need to special case onfoo listeners. 54352 7 bugs 2011-08-07 08:10:36 +0000 And also, onfoo listeners have been discussed in WebApps WG, and decided that they are no special, which is why D3E doesn't even try to define them. 54414 8 ian 2011-08-08 21:56:10 +0000 Will examine further. Things to test: Order of handlers in addEventListener(), set onhandler, addEventListener() Order of handlers in set onhandler, addEventListener(), set onhandler Whether it matters if you're removing and resetting the attribute, vs changing the attribute. Whether the IDL attributes behaves differently. 54450 9 bugs 2011-08-09 10:38:38 +0000 Gecko seems to keep the onfoo in its place in the event listener list if one changes (not removes) the onfoo listener. chrome and opera don't do that, but apparently remove the old listener first and then add new. I'm ok changing Gecko's behavior. 57072 10 annevk 2011-09-21 16:47:14 +0000 Pretty sure this needs a hook in DOM4 (DOM Level 3 Events is wrong in that they are nothing special). http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1143 Using both addEventListener and on* you can register the same listener twice. And you cannot remove the listener added with addEventListener by setting on* to null, etc. I think event listener needs an additional "event handler flag". When you set on* it first removes any event listeners for type=type, listener=listener, event handler flag set, then it appends a new event listener for type=type, listener=listener, with the event handler flag set. addEventListener meanwhile never has the event handler flag set and when doing equality checking it always checks for unset. 57073 11 jrossi 2011-09-21 16:56:32 +0000 IE matches Firefox in that once on* is set, its position in the ordering is fixed. Changing on* changes the listener but not the order. 57074 12 annevk 2011-09-21 17:03:04 +0000 If we want that behavior, instead of removing it should then simply change the original entry, if any, and append otherwise, when setting the event handler to a new value. Hixie, do you agree that http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-event-listener needs a "event handler flag"? (I will also turn capture into a "capture flag" for consistency.) (I realize we talked about moving event handlers into DOM4, but we should probably wait with that some more.) 57078 13 ian 2011-09-21 17:28:04 +0000 Setting on* to a function foo does not register a listener for foo. The listener that is actually registered is an anonymous function that then calls foo. So there's no conflict with aEL() here. 57694 14 annevk 2011-10-03 10:00:14 +0000 Hixie, where does HTML state that? I cannot find such a thing for event handler IDL attributes. 57929 15 ian 2011-10-07 04:17:05 +0000 Search for the following text (also partly quoted in comment 5 above): -----8<----- All event handlers on an object, whether an element or some other object, and whether set to null or to a Function object, must be registered as event listeners on the object when it is created, as if the addEventListener() method on the object's EventTarget interface had been invoked, with the event type (type argument) equal to the type corresponding to the event handler (the event handler event type), the listener set to be a target and bubbling phase listener (useCapture argument set to false), and the event listener itself (listener argument) set to do nothing while the event handler's value is not a Function object, and set to invoke the call() callback of the Function object associated with the event handler otherwise. Note: Event handlers therefore always run before event listeners attached using addEventListener(). Note: The listener argument is emphatically not the event handler itself. -----8<----- If I understand correctly, this bug is about changing this so that instead of this happening when the element is created, it happens when the event handler is first set to something other than null. 57930 16 ian 2011-10-07 04:18:21 +0000 (Also I'll clarify the text so that it doesn't state by confusingly saying that the "event handlers [are] registered as event listeners" since that's not what the text goes on to actually require.) 57966 17 ian 2011-10-07 21:21:25 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, 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 Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. 57967 18 contributor 2011-10-07 21:45:16 +0000 Checked in as WHATWG revision r6652. Check-in comment: Define how event handler registration works to be compatible with IE and Firefox. http://html5.org/tools/web-apps-tracker?from=6651&to=6652 1021 2011-08-05 10:10:46 +0000 2011-08-05 10:10:46 +0000 testcase onfootest.html text/html 646 bugs PGh0bWw+CiAgPGhlYWQ+CiAgICA8c2NyaXB0PgogICAgCiAgICAgIGZ1bmN0aW9uIGNsaWNrKCkg ewogICAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJsIikudGV4dENvbnRlbnQgKz0gImFk ZEV2ZW50TGlzdGVuZXIgbGlzdGVuZXIgdHJpZ2dlcmVkIFxuIjsgCiAgICAgIH0KICAgICAgCiAg ICAgIAogICAgICBmdW5jdGlvbiBjbGlja09uRm9vKCkgewogICAgICAgIGRvY3VtZW50LmdldEVs ZW1lbnRCeUlkKCJsIikudGV4dENvbnRlbnQgKz0gIm9uZm9vIGxpc3RlbmVyIHRyaWdnZXJlZCBc biI7IAogICAgICB9CiAgICAgIAogICAgICBmdW5jdGlvbiBzZXR1cCgpIHsKICAgICAgICBkb2N1 bWVudC5nZXRFbGVtZW50QnlJZCgiaSIpLmFkZEV2ZW50TGlzdGVuZXIoImNsaWNrIiwgY2xpY2ss IGZhbHNlKTsKICAgICAgICBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgiaSIpLnNldEF0dHJpYnV0 ZSgib25jbGljayIsCiAgICAgICAgICAiY2xpY2tPbkZvbygpIik7CiAgICAgIH0KICAgIDwvc2Ny aXB0PgogIDwvaGVhZD4KICA8Ym9keSBvbmxvYWQ9InNldHVwKCk7Ij4KICAgIDxpbnB1dCBpZD0i aSIgdmFsdWU9ImNsaWNrIG1lIiB0eXBlPSJidXR0b24iPgogICAgPHByZSBpZD0ibCI+PC9wcmU+ CiAgPC9ib2R5Pgo8L2h0bWw+Cg==