Re: [w3c/uievents] Different click event order behavior between Firefox , ie , edge and Chrome/Safari (#303)

@mustaqahmed 
From [For each](https://infra.spec.whatwg.org/#list-iterate)
> To iterate over a list, performing a set of steps on each item in order, use phrasing of the form "For each item of list", and then operate on item in the subsequent prose.

and from [event handlers](https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects)
>The event listener registration happens only if the event handler's value is being set to non-null, and the event handler is not already activated. Since listeners are called in the order they were registered, assuming no deactivation occurred, the order of event listeners for a particular event type will always be:
>
> 1. the event listeners registered with addEventListener() before the first time the event handler's value was set to non-null
>
> 2. then the callback to which it is currently set, if any
>
> 3. and finally the event listeners registered with addEventListener() after the first time the event handler's value was set to non-null.

Note: a **list** is an ordered collection of items as opposed to a **set** which is specifically not ordered or a generic **collection** which is or isn't ordered, depending upon the implementation.

@TurnerXi
> When I click the target element , it should be at-target ph(r)ase and trigger by listener order, but Chrome / Safari doesn’t .

Actually, according to [W3 standard](https://www.w3.org/TR/DOM-Level-3-Events/#event-flow), all events propagate from the top level (window/html element) **to** the target and then back out again. These are the (respectively) capture phase and bubble phase. The calls to `addEventListener` specify that listener **a** is *not* in the capture phase (capture == false) while **a1** *is* in the capture phase (capture == true) thus **a1** should execute before **a** irrespective of the "order" of the listeners (defined by their creation order). So, in fact, Chrome / Safari are "correct" while the others are not. Some [investigation](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener) ***suggests*** that this is because these browsers do not recognise the distinction between capturing and bubbling, processing events using only one of the phases (browser dependent) and ignoring the `capture` flag. Thus, since both listeners are attached to the same element, the event reaches them at the same time and the listener list order then decides which executes first.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/303#issuecomment-1011736566

You are receiving this because you are subscribed to this thread.

Message ID: <w3c/uievents/issues/303/1011736566@github.com>