w3c / uievents

UI Events
https://w3c.github.io/uievents/
Other
145 stars 51 forks source link

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

Open smaug---- opened 4 years ago

smaug---- commented 4 years ago

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 https://github.com/w3c/pointerevents/issues/285

smaug---- commented 3 years ago

@garykac, any comments?

garykac commented 3 years ago

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:

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

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 commented 3 years ago

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 commented 3 years ago

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

smaug---- commented 3 years ago

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 commented 3 years ago

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.