1944191 - `mousemove` should not be fired on the `Document` node if preceding boundary event removed the target and there is the last deepest `mouseenter` event target

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Chrome stops dispatching mousemove or pointermove if its preceding boundary event causes removing the target.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh, if mouseover target is just removed, Chrome dispatches a mousemove on the connected ancesto. However, if mouseover target is replaced, i.e., the element under the cursor is not a target of the enter targets, Chrome does not dispatch mousemove.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Err, no. Chrome fires mousemove on the connected ancestor even if the target is replaced. Hmm.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Chrome may change the behavior because they behave differently with/without the experimental feature, and we don't need this bug for bug 1943411. So, we should close this bug for now.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Okay, we should dispatch pointermove and mousemove on the last deepest "enter" event target (i.e., next deepest "leave" event target).

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Try: https://treeherder.mozilla.org/jobs?repo=try&resultStatus=usercancel%2Csuperseded%2Ctestfailed%2Cbusted%2Cexception%2Csuccess%2Cretry%2Crunning%2Cpending%2Crunnable&revision=bd411dfe6e0f4c6485ded787251e05cbc7e9c2d3

I got same result with Chrome Canary with enabling the new boundary event behavior for mouse, but it seems that Chrome Canary stops dispatching in pointer event case.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Safer one (limiting only for eMouseMove):
https://treeherder.mozilla.org/jobs?repo=try&resultStatus=usercancel%2Csuperseded%2Ctestfailed%2Cbusted%2Cexception%2Csuccess%2Cretry%2Crunning%2Cpending%2Crunnable&revision=231501c4f840462515eca5ec03e525f64e87330e

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1944191 - Make `PresShell::EventHandler::DispatchEvent` retarget `mousemove` event if preceding boundary events removed the target r=smaug!

Chrome dispatches mousemove/pointermove event on the preceding mouseover
or pointerover target even if the target is removed from the DOM tree.
However, once the "Boundary Event Dispatch Tracks Node Removal" feature is
enabled, Chrome Canary dispatches mousemove/pointermove on the last
deepest mouseenter/pointerenter event target which is still connected.
Therefore, we should follow their new behavior if it's simply possible.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/be17ac5dd59b
Make `PresShell::EventHandler::DispatchEvent` retarget `mousemove` event if preceding boundary events removed the target r=smaug

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/50339 for changes under testing/web-platform/tests

Comment 10

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/be17ac5dd59b

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1944191 - Make `PresShell::EventHandler::DispatchEvent` retarget `mousemove` event if preceding boundary events removed the target r=smaug!

Chrome dispatches mousemove event on the preceding mouseover target even if
the target is removed from the DOM tree. However, once the
"Boundary Event Dispatch Tracks Node Removal" feature is enabled, Chrome Canary
dispatches mousemove on the last deepest mouseenter event target which is
still connected. Therefore, we should follow their new behavior if it's simply
possible.

Note that if pointeover target is removed, Chrome does not dispatch
pointermove on the last deepest pointerenter target. Therefore, this patch
limits the behavior change only for eMouseMove.

Original Revision: https://phabricator.services.mozilla.com/D235807

Comment 13

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Cannot use the menu in https://www.eclecticgames.co.uk/
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Go to https://www.eclecticgames.co.uk/ and move mouse cursor over the link under the searchbox, then, move the cursor down to over the popuped menu (the menu was closed when you move the mouse cursor on it)
• Risk associated with taking this patch: Low
• Explanation of risk level: The new behavior is redirecting mousemove event to nearest its ancestor which is still in the DOM tree. This does not match with current Chrome, but it's same as newer behavior of Chrome. Additionally, currently dispatchingmousemove onto the Document node is illegal from the UI Events spec.
• String changes made/needed: none
• Is Android affected?: yes

Comment 14

[Peter Magyari (Desktop QA)]

Reproducible on 136.0a1 (20250127162202) and verified fixed on 136.0a1 (20250129050021).

Comment 15

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/cafdc383bae5

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Added to the 135.0.1 relnotes.

Fixed drop-down menus being unusable on some sites relying on certain mousemove event behavior.

Comment 17

[Peter Magyari (Desktop QA)]

Verified fixed using Firefox 135.0.1 (20250213194722) downloaded from Comment 15.