Need clarification how mouseenter/leave should behave while modifying DOM tree during event dispatch

[smaug----]

It isn't clear which elements should get mouseenter/leave events if DOM is modified during dispatching one of the events.

Pointer events variant of this bug is w3c/pointerevents#285

[smaug----]

@garykac, any comments?

[garykac]

I wrote up a proposed algorithm for handling mouse events, but I haven't yet thought deeply about the best way to handle DOM mutations.

The proposed algorithm ensures that every element that receives a mouseenter will receive a mouseleave even if the element is moved, but there may be other concerns that should be taken into account.

WRT the pointerevent example in the other bug, I would have expected the pointer enter/leave events to match the mouse enter/leave events.

Naively, I would have guessed either:

• mouse/pointer enter top
• mouse/pointer enter middle
• mouse/pointer enter bottom
• mouse/pointer leave bottom
• mouse/pointer leave middle

Or possibly simply (if the elements are removed before any events are sent):

• mouse/pointer enter top

The first example most closely matches Safari except the the extra mouse/pointerenter at the end. It's odd that all browsers generate the unnecessary "pointerenter top" at the end.

[garykac]

On this mouseevents test page, if you enter from the right side (where the 3 divs align), you do get 3 mouseenter events when you enter "C". This is similar to the other example, but without the DOM mutation.

It's a bit concerning that Chrome/Firefox apparently have different paths for the corresponding mouse and pointer events.

Even if you ignore the DOM mutation, Safari interleaves the mouse/pointer events while Chome/Firefox group each type together. I think that interleaving them is more appropriate if we expect mouse and pointer events to be somewhat interchangeable.

[garykac]

Another note: need to test DOM manipulations during Capture vs. AtTarget vs. Bubbling.

[smaug----]

The problem with interleaving is that enter/leave happen because of reaction to some *over/*out. So if mouseover is dispatched, there should be corresponding mouseenter events. But I think whether or not to interleave should be left to w3c/pointerevents#285 or some other pointer events spec issue.

But for the overall enter/leave handling, the main worry I have is that leave event might happen way way after the element has been removed. If some script removes the element under the cursor when pointer isn't moving, there won't be any events, but then later when pointer is moved, you'd get *leave for the removed elements.
Other than that the behavior feels reasonable to me (even though it is different to what Chrome or Firefox do).

[garykac]

But I think whether or not to interleave should be left to w3c/pointerevents#285 or some other pointer events spec issue.

That works for me. I just need to know which way we go so that I can add appropriate hooks into the proposed algorithm.

I've added a note to the doc with a link to that PE issue.