Open Bug 1630462 Opened 4 years ago Updated 1 year ago

Cursor drift when using the pointer lock API when not in fullscreen.

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Version:
75 Branch
Platform:
Desktop
Linux
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox87 - wontfix

People

(Reporter: george.beers13, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

test case
1.50 KB, text/html
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

I clicked on the canvas in the mozilla pointer lock demo (https://mdn.github.io/dom-examples/pointer-lock/) when not in fulllscreen.

Actual results:

The cursor drifted diagonally (-1, -1) even when I didn't touch the trackpoint.

Expected results:

It shouldn't have drifted.

I should add that this doesn't happen in chromium.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Canvas: 2D
Product: Firefox → Core

Bugbug might be wrong this time.

Component: Canvas: 2D → DOM: UI Events & Focus Handling
OS: Unspecified → Linux
Hardware: Unspecified → Desktop

I don't experience the problem on Ubuntu with FF 75.
Could you provide more information for reproducing the problem?

Flags: needinfo?(george.beers13)

The problem happens whenever my cursor is locked when not in fullscreen. It happens on any website that uses the pointer lock API. I'm on Void Linux, but I think the problem might be because I use the trackpoint and not the trackpad on my X230. A friend using an x260 also found that their cursor would drift in the same way in any pointer locked website.

Flags: needinfo?(george.beers13)

Resetting severity to default of --.

I can't reproduce on Fedora 31, Thinkpad P51 using trackpad.

I recall seeing drifting with trackpoint in general (not related to pointer lock or Firefox), but I need to test if I can reproduce if I enable trackpoint.

Priority: -- → P3

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Severity: normal → S3

I can reproduce this in FF 77.0.1. I am getting a drift of (-2, 0).

I'm using the i3 window manager, and I think the borders of my windows are 2 pixels. I wonder if this could be related.

I cannot reproduce in Chromium.

Also reproducing in the i3 window manager, on FF 78.0.2.

Changing the window into borderless mode stops the drift, so it is indeed related.

I can confirm that this is still happening in Firefox 87.0 on Windows 64 bit.

After some testing with different mice and and machines I can reproduce it consistently.
It happens only when the browser tab is located on a high-resolution Monitor (I have 4K) and when windows UI scaling is active (I have 150%).

confusingly I cannot record the behaviour, because when I record it (using Screen2Gif) it does not happen.
For me it is a slow constant drift downwards. in some random positions it stops drifting, but immidiately starts again after I move the mouse.

confirmed in Firefox 87.0 on Windwos 64 bit

status-firefox87: --- → affected
tracking-firefox87: --- → ?

Longstanding issue, not tracking for 87.

status-firefox87: affected → wontfix
tracking-firefox87: ? → -

Same issue here with Nightly 95.0a1 on Arch, I’ve been having this problem for a some time now.

I am using bspwm, the cursor drift is [-2, -2]. The borders of my windows are 2 pixels, so it might indeed be the issue.

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

Status: UNCONFIRMED → NEW
Ever confirmed: true

Still exists in FF 100.

Attached file test case —

I can reproduce this on Pop!_OS 22.04 (Xorg). It happens with both hidpi enabled (200% scaling) and without hidpi enabled. Whether the drift occurs or not seems to depend on the location and dimensions of the window. If you cannot reproduce the bug, try moving or resizing the window by a single pixel at a time. The bug can also be triggered if the sidebar is showing (again, it depends on the width).

My guess is that this is a rounding error. The pointer lock code hides the pointer and tries to keep it centered in the window. If the calculated center coordinates are not a round number, I'm guessing that it leads to the drifting behaviour described here.

Blocks: pointer-lock
See Also: → 1790988

Another symptom of this bug (even when the cursor doesn't drift), is that it's not possible to move a locked pointer right or up in 1 pixel increments. But you can move left/down in 1 pixel increments. You can try this out by running watch -n 0.1 xdotool mousemove_relative -- 1 -1 in a terminal then trying the above test case. When the pointer is locked, the circle doesn't move. If you instead run watch -n 0.1 xdotool mousemove_relative -- -1 1 the circle does move as expected. Again I can reproduce this behaviour on Pop!_OS 22.04 but not on Ubuntu 22.04.

I'm pretty sure this bug is caused in UIEvent::getMovementPoint() by the DevPixelsToCSSPixels conversion on the delta between the current and last mouse coordinates. The pointer lock spec states that movementX/Y is meant to be the difference between the current and last screenX/Y values. However MDN points out that this isn't actually the case due to complicated reasons. I would suggest that this bug would be fixed by basing movementX/Y on screenX/Y when the pointer is locked, but not otherwise.

As mentioned above, this is triggered by non-integer display scaling on Firefox (see "Window Device Pixel Ratios" in about:support). I can reproduce in Ubuntu 22.04 when enabling "Large Text" in the Accessibility Settings which sets the device pixel ratio to 1.25.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: