1254044 - Undesired mouse move events are triggered when entering or exiting pointer lock

Status: NEW

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

Description

[Xidorn Quan [:xidorn] UTC+10]

Attachment: testcase

Steps to reproduce:
1. open the attached testcase
2. click the "fullscreen" button and do not move the pointer anymore
3. wait for ~5s, seeing the pointer disappears and re-appears

Expected result:
Only two lines should be printed: "pointer locked" and "pointer unlocked"

Actual result:
Two extra "mouse move" lines are printed as well


This bug doesn't hurt real cases much. Actually it seems to me Blink currently does much worse than us (they trigger far more unnecessary events). But it could affect our tests. So it's probably worth some investigation.

Comment 1

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Xidorn, is this bug a must fix for 50? or a fix-optional? It sounds like a fix-optional if there isn't a noticeable end-user impact from this bug.

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

Right, I don't think this one has a high priority. Our pointerlock test works pretty good after fixing bug 931445.

Comment 3

[Jukka Jylänki]

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #0)
> This bug doesn't hurt real cases much. Actually it seems to me Blink
> currently does much worse than us (they trigger far more unnecessary
> events). But it could affect our tests. So it's probably worth some
> investigation.

Hi, I'd like to ask to bump up the priority of this bug. Changing the STR a little bit from Comment 0 uncovers a somewhat critical bug in the handling of mouse movement values:

Updated steps to reproduce:
1. open the attached testcase
2. click the "fullscreen" button and do not move the pointer after clicking
3. wait until the pointer disappears (this is timed in the test) and the text "pointer locked" appears on screen.
4. after the pointer has disappeared, start slowly moving the mouse cursor to the right.
This will cause relative mouse movement with small +X values to be printed on screen.

5. Once the cursor reappears (this is timed as well), stop panning the mouse, and observe the printed values.

Observed:

the log reads

>// this is when fullscreen button was pressed
>pointer locked
>// this is when pointer is timed to disappear, start slowly panning mouse to the right:
>mouse move: 67,102; 1,0
>mouse move: 67,102; 1,0
>mouse move: 67,102; 1,0
>mouse move: 67,102; 2,0
>mouse move: 67,102; 1,0
>mouse move: 67,102; 3,0
>mouse move: 67,102; 1,0
>mouse move: 67,102; 4,0
>// the test prints out (absolute X, absolute Y, relative X, relative Y) values
>// small mouse +X delta values keep being printed as mouse is being panned:
>mouse move: 67,102; 2,0
>mouse move: 67,102; 1,0
>mouse move: 67,102; 4,0
>mouse move: 67,102; 4,1
>...
>mouse move: 67,102; 2,0
>mouse move: 67,102; 2,0
>mouse move: 67,102; 2,0
>// this is when the mouse cursor reappears
>pointer unlocked
>mouse move: 1282,720; 1215,618 // should not happen
>mouse move: 1285,720; 3,0 // should not happen
>mouse move: 68,102; -1217,-618 // should not happen
>mouse move: 69,102; 1,0
>mouse move: 72,102; 3,0
>mouse move: 74,102; 2,0
>mouse move: 79,102; 5,0
>mouse move: 83,102; 4,0

In particular, observe how there are massive `movementX` and `movementY` deltas (1215,618) and (-1217,-618) reported back to back. Notice how this value (1215,618) corresponds to the delta between where the mouse cursor was at when one initially locked the mouse at, (67,102), and where the mouse cursor was later unlocked, (1282, 720). I.e.  (1282, 720) - (67,102) = (1215,618). So it looks like when mouse cursor is unlocked, Firefox reports a large delta to where the mouse cursor was originally locked at (and then snaps back to the opposite direction).

The intended behavior I believe when one unlocks the mouse seems to be that the mouse cursor should reappear in the original coordinate where it was originally hidden/locked at. This does happen in Firefox, but note how for two frames, the mouse cursor is reported to be at coordinate (1282, 720) before resetting it back to (68,102). So it looks like this resetting somehow "leaks" some time, and intermittently the mouse cursor is shown to be at whereever one moved it to when it was hidden.

This causes very jarring effects in applications that control some element by relative mouse motion, e.g. drag a slider value by holding down and drag left-right, or drag the mouse to rotate a camera lookat direction in a WebGL application.

This was tested on Windows 10 64-bit on Firefox 59.0.3 (64-bit).