2071024 - [macOS] Coalesced `pointerrawupdate` events report movementX/Y = 0 during pointer lock while the dispatched event carries the correct delta

Status: RESOLVED FIXED

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

Description

[jbedwell]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/153.0.0.0 Safari/537.36

Steps to reproduce:

1. Open the attached test page on macOS
2. Click the blue area to enter pointer lock
3. Move the cursor continuously

This page shows a red cursor driven by dispatched events when the coalesced list is broken and a blue one driven strictly by the coalesced entries.

Actual results:

Observe the red cursor deviate from the blue cursor.

During pointer lock dispatched pointerrawupdate events report correct non-zero movement X/Y, but coalesced entries report movement X/Y = 0. The test page flags these as broken events. This reproduces in adjusted and unadjusted pointer lock modes.

Expected results:

Each coalesced pointerrawupdate entry reports movement X/Y which is equal to the sum of the coalesced event movements. Both cursors track the mouse, test page reports OK.

Comment 1

[jbedwell]

Attachment: pointer_lock_test2.html

Comment 2

[jbedwell]

On macOS with pointer lock active, every entry returned by getCoalescedEvents() for a pointerrawupdate event reports movementX and movementY = 0, while the dispatched pointerrawupdate event itself reports the correct non-zero movement delta. The pointerrawupdate event movement delta should equal the sum of the movement delta of its coalesced events.

This affects applications that consume high frequency mouse input via pointerrawupdate + getCoalescedEvents() during pointer lock on macOS.

This appears to be the same class of issue as bugs 1829401 and 1987671 which concerned movement on the dispatched parent event. Based on https://github.com/w3c/pointerevents/issues/535 and behavior on Windows it appears that the behavior observed in this bug is not intended.

Testing done on macOS 26.6.2 + Firefox 155.0.0 / 155.0.1.

Comment 3

[Edgar Chen [:edgar]]

Yes, this looks like a bug to me, I will take a look.

Comment 4

[Donal Meehan [:dmeehan]]

:edgar, is Bug 2036482 potentially the regressor here?

Comment 5

[Edgar Chen [:edgar]]

Yes, I think so, I could not reproduce this after setting dom.pointer-lock.native-lock.enabled to false.

Comment 6

[BugBot [:suhaib / :marco]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 7

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #5)

Yes, I think so, I could not reproduce this after setting dom.pointer-lock.native-lock.enabled to false.

BTW, I see the same behavior on Linux, but setting dom.pointer-lock.native-lock.enabled to false doesn't help.
So it might be different root cause on Linux.

---

Edited:
Linux Wayland doesn't use that pref at all.

Comment 8

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=93565

Comment 9

[Edgar Chen [:edgar]]

Attachment: Bug 2071024 - Part 3: Propagate mMovement to the coalesced pointer event; r?smaug

ePointerRawUpdate never has coalesced widget events to report, so
EnsureFillingCoalescedEvents() synthesizes a single entry from the dispatched
event via InitCoalescedEventFromPointerEvent(), which copied every member but
mMovement.

Comment 10

[Edgar Chen [:edgar]]

Attachment: Bug 2071024 - Part 1: Support synthesizing mouse event with movement delta; r?smaug

movementX and movementY are optional and have to be specified together.

Comment 11

[Edgar Chen [:edgar]]

Attachment: Bug 2071024 - Part 2: Add test for movementX/Y during pointer lock; r?smaug

The expected result for coalesced event is based on current behavior, which may
be incorrect and will be fixed in subsequent patches.

Comment 12

[Edgar Chen [:edgar]]

Attachment: Bug 2071024 - Part 4: Allow mousemove events that carry movement deltas to be coalesced; r?smaug

CanCoalesce() incorrectly required the movement deltas of both events to be
equal, so mousemove events carrying movement deltas were effectively never
coalesced.

Comment 13

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=95141

Comment 14

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=95724

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/55cbc56fd926
https://hg.mozilla.org/integration/autoland/rev/c672294d2d75
Part 1: Support synthesizing mouse event with movement delta; r=smaug,webidl
https://github.com/mozilla-firefox/firefox/commit/efcc9087b49f
https://hg.mozilla.org/integration/autoland/rev/3c0523a23730
Part 2: Add test for movementX/Y during pointer lock; r=smaug
https://github.com/mozilla-firefox/firefox/commit/3d4fb7a1cf19
https://hg.mozilla.org/integration/autoland/rev/c91e97674283
Part 3: Propagate mMovement to the coalesced pointer event; r=smaug
https://github.com/mozilla-firefox/firefox/commit/df43b134c3da
https://hg.mozilla.org/integration/autoland/rev/b42c0de1a856
Part 4: Allow mousemove events that carry movement deltas to be coalesced; r=smaug

Comment 16

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/c672294d2d75
https://hg.mozilla.org/mozilla-central/rev/3c0523a23730
https://hg.mozilla.org/mozilla-central/rev/c91e97674283
https://hg.mozilla.org/mozilla-central/rev/b42c0de1a856