*** Bug 13683 has been marked as a duplicate of this bug. ***

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?

Event listeners are called in the order they are added to the event target.

I couldn't figure out what in the spec leads to "therefore always".

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

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.

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.

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.

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.

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.

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.

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

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.

Hixie, where does HTML state that? I cannot find such a thing for event handler IDL attributes.

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.

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

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.

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