[w3c/uievents] Clearify whether `mouseover`, `mouseout`, `mouseenter` and `mouseleave` are fired or not fired when the target is removed by `mousedown` or `mouseup` (Issue #359)

[mouseenter](https://w3c.github.io/uievents/#event-type-mouseenter)
> A [user agent](https://w3c.github.io/uievents/#user-agent) MUST also dispatch this event when the element or one of its descendants moves to be underneath the primary pointing device.

[mouseleave](https://w3c.github.io/uievents/#event-type-mouseleave)
> A [user agent](https://w3c.github.io/uievents/#user-agent) MUST also dispatch this event when the element or one of its descendants moves to be no longer underneath the primary pointing device.

[mouseout](https://w3c.github.io/uievents/#event-type-mouseout)
> A [user agent](https://w3c.github.io/uievents/#user-agent) MUST dispatch this event when <snip> or when the element is moved to be no longer underneath the primary pointing device.

[mouseover](https://w3c.github.io/uievents/#event-type-mouseover)
> A [user agent](https://w3c.github.io/uievents/#user-agent) MUST dispatch this event when <snip> or when the element is moved to be underneath the primary pointing device.

I wrote [this tentative test](https://searchfox.org/mozilla-central/rev/a1827d62f97d9721993ba489f4af7dea422d418f/testing/web-platform/tests/uievents/mouse/synthetic-mouse-enter-leave-over-out-button-state-after-target-removed.tentative.html) and [the result is here](https://wpt.fyi/results/uievents/mouse/synthetic-mouse-enter-leave-over-out-button-state-after-target-removed.tentative.html%3FbuttonType%3DLEFT%26button%3D0%26buttons%3D1?label=experimental&label=master&aligned) and [here](https://wpt.fyi/results/uievents/mouse/synthetic-mouse-enter-leave-over-out-button-state-after-target-removed.tentative.html%3FbuttonType%3DMIDDLE%26button%3D1%26buttons%3D4?label=experimental&label=master&aligned)

The expectation of the test is:
1. When `mousedown` or `mouseup` listener removes the event target, `mouseout` and `mouseleave` should be fired on the removed element because `mouseover` and `mouseenter` were already fired on it and it's now moved to be "no longer underneath the primary pointing device".
2. Then, `mouseover` should be fired on the parent of the removed element because it's not been received  `mouseover` yet but it's now "moved to be no longer underneath the primary pointing device".
3. However, `mouseenter` should not be fired on any elements because `mouseneter` has already been fired on the inclusive ancestors of the removed elements.

Unfortunately, Safari fails the test with ERROR. Therefore, we can check only the result of Chrome and Firefox for now.

Actual result of both of them in the first list item case is, both Chrome and Firefox do not fire the events on the removed node. Therefore, I suggest that they should be clarified as "never fired on targets which are not connected to the document node".

Then, in the second list item case, both Chrome and Firefox fire `mouseover` event on the parent node (Although Chrome's `buttons` value is wrong for non-primary button). I think that this is reasonable and web apps in the wild may depend on this event even though `pointerover` is defined as it should be fired only when the pointer moves. In other words, dispatching `mouseover` in this case is not consistent with Pointer Events, but keep dispatching it may be important for keeping the backward compatibility.

Finally, in the last list item case, both Chrome and Firefox dispatch `mouseenter` too because they lost the last `mouseenter` element due to the removal. So, I think that this is an issue of the approach to implement `mouseenter` event, whether browsers store only the deepest descendant or all inclusive descendants from the root elements.

My conclusion is, only the `mouseout` and `mouselaeve` expectations should be changed and this case should be clarified in the spec, maybe in [the event order section](https://w3c.github.io/uievents/#events-mouseevent-event-order)?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/359
You are receiving this because you are subscribed to this thread.

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