2055058 - pointerrawupdate leaks cursor reset correction events on Windows in pointer lock, causing excessive movement accumulation at high mouse polling rates

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Ananta Iyengar]

Attachment: image.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36

Steps to reproduce:

1. Open a page (e.g https://tests.eirage.com/PointerLock/PointerLockLog.html#) that uses requestPointerLock() with unadjustedMovement: true on Windows + Firefox 152
2. Register both pointermove and pointerrawupdate listeners simultaneously
3. Log movementX, movementXSum (running total), and coalescedEvents count for each event
4. Enter pointer lock and move the mouse continuously in one direction (e.g. right)
   Compare the running movementXSum between pointermove and pointerrawupdate

Actual results:

pointermove coalesced events include negative correction deltas (e.g. -5, -16, -11) that cancel out the cursor reset, giving a correct net delta. pointerrawupdate contains only positive deltas with no corresponding corrections, causing movementXSum to diverge from pointermove's sum over time. This makes the mouse feel significantly too fast when using pointerrawupdate.

Expected results:

Both pointermove and pointerrawupdate should report the same net movement. Cursor reset correction events should be suppressed before being exposed via either event type, as Chrome does correctly.

Notes:
pointermove + getCoalescedEvents() behaves correctly — correction events cancel naturally within the coalesced batch

pointerrawupdate fires before the correction event is generated or absorbed, so the correction is never seen by the page

Chrome suppresses correction events correctly on both pointermove and pointerrawupdate

Issue confirmed on Firefox 152.0.5, Windows 11

Significantly worse with 1000Hz gaming mice vs 125Hz standard mice
unadjustedMovement: true (now supported in Firefox 152 via Bug 2037802) makes
this more visible since OS level smoothing no longer masks the effect

Evidence: side by side log of pointermove vs pointerrawupdate showing diverging movementXSum and missing correction events in pointerrawupdate (screenshot attached)

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Events' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Dianna Smith [:diannaS]]

:echen could this have been caused by bug 2036904?

Comment 3

[Edgar Chen [:edgar]]

Thanks for reporting this, Ananta!
There has been a recent improvement to pointer lock in bug 1255338. I think it also improves pointer lock behavior on Windows.
Would you mind trying the latest Nightly build to see if you can still reproduce the issue?

Comment 4

[Edgar Chen [:edgar]]

(In reply to Dianna Smith [:diannaS] from comment #2)

:echen could this have been caused by bug 2036904?

bug 2036904 is the one that implement the unadjustedMovement support on Windows.
But I think this is an existing issue, unadjustedMovement just make it more obvious.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

This was fixed by bug 1255338.