Open masayuki-nakano opened 11 months ago
A 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.
Hello there 👋
quick derived use-case → what about one of the descendant, which was absolutely positioned, and thus visually not over the element boundary, is removed from the DOM. The pointer did not move, and technically the element is not underneath it.
I would expect the mouseleave
to be fired in this case. Am i right? (spoiler it is not fired as of today)
Current agreements in https://github.com/web-platform-tests/interop/issues/380:
mouseout
event nor mouseleave
event should be fired on the removed node(s)mouseenter
targets should be kept even after the last mouseover
target is removed, thus, the pairs of mouseenter
and mouseleave
are kept and can prevent redundant mouseenter
events on the ancestors.I also added a new WPT for testing the mouse boundary events at first mousemove
after a click
event listener removes its target. Its result is here.
Ccing @garykac, @mustaqahmed, @zcorpan and @smaug----
mouseenter
mouseleave
mouseout
mouseover
I wrote this tentative test and the result is here and here
The expectation of the test is:
mousedown
ormouseup
listener removes the event target,mouseout
andmouseleave
should be fired on the removed element becausemouseover
andmouseenter
were already fired on it and it's now moved to be "no longer underneath the primary pointing device".mouseover
should be fired on the parent of the removed element because it's not been receivedmouseover
yet but it's now "moved to be no longer underneath the primary pointing device".mouseenter
should not be fired on any elements becausemouseneter
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'sbuttons
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 thoughpointerover
is defined as it should be fired only when the pointer moves. In other words, dispatchingmouseover
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 lastmouseenter
element due to the removal. So, I think that this is an issue of the approach to implementmouseenter
event, whether browsers store only the deepest descendant or all inclusive descendants from the root elements.My conclusion is, only the
mouseout
andmouselaeve
expectations should be changed and this case should be clarified in the spec, maybe in the event order section?