Note

• When the user opens the browser with wayland window manager and loads this game, he will notice that mouse navigation is severely impaired; the speed at which the cursor is moving (in-game) is very slow.

Affected versions

• Nightly v96.0a1

Affected platforms

• Ubuntu 21 + wayland

Steps to reproduce

1. Launch browser with wayland window manager:
   a. Go into the nightly folder.
   b. Right-click and "Open in Terminal".
   c. MOZ_ENABLE_WAYLAND=1
   d. ./firefox
2. Load https://classic.minecraft.net
3. Type in a username and click "Start".

Expected result

• The in-game mouse navigation should be comfortable to use for a normal game-play.

Actual result

• The in-game mouse navigation is severely impaired, in the sense that the speed at which it's moving is much too slow for a normal playing environment.

Regression range

• unknown.

Additional notes

• This issue occurs with "wayland" Window Protocol and not with "xwayland".

Greg, do you have an idea what could be wrong here? And do you think it's a Firefox or compositor issue?

The implementation of pointer lock on Wayland provides unaccelerated movement. In the pointer lock demo, notice how the circle moves noticeably slower than an unlocked mouse cursor.

Having unaccelerated movement available to the application is desirable, in principle, as it allows the application to define its own speed and acceleration when mouse movement does not steer a cursor.

However, it is contrary to the spec, which specifies that the movement deltas provided should match the system cursor, acceleration and all.

this specification defines the movement deltas to be taken from how the system mouse cursor moves, which incorporates operating system filtering and acceleration of the mouse movement data

So it also breaks the use case of emulating a confined cursor given just movement deltas, where the locked cursor should move identical to an unlocked one.

I suspect using dx_w and dy_w instead of dx_unaccel_w and dy_unaccel_w in relative_pointer_handle_relative_motion will fix this.

https://searchfox.org/mozilla-central/rev/21f0bb70ce5747d18625ad1c67f03ed2af7f9c56/widget/gtk/nsWindow.cpp#9104-9105

Jan, do you mind to create a patch for it?
Thanks!

Patch suggested by Jan Alexander Steffens <jan.steffens@gmail.com>

From the spec (https://w3c.github.io/pointerlock/):

this specification defines the movement deltas to be taken from how
the system mouse cursor moves, which incorporates operating system
filtering and acceleration of the mouse movement data

Lets try! https://treeherder.mozilla.org/jobs?repo=try&revision=7960d35b0b5f6a3511f91f30e9e493c894694629

Edit: https://treeherder.mozilla.org/jobs?repo=try&revision=b77e0e909e85bbfc59b5d6863c5df137909c8daa&selectedTaskRun=RXYnqE2rQMi_c3XuvCFYXQ.0 for the double->int change, but as expected it doesn't seem to change anything.

Yep, with the try build from comment 6, the pointer lock demo from comment 2 now behaves as it should for me.

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

It appears that this issue still reproduces with the latest Beta v96.0b5 which contains the fix.
NeedInfo me for more info and/or testing.

Hm, yeah, I somewhat suspected this to not be completely right because we do not take scaling into account. Will revisit, keeping ni active.

Bodea: can you shortly elaborate about your setup? Most notably: do you use buffer scaling (something like 200% in the display settings of the OS)? And do you have any default zoom setting in Firefox set (usually a number like 90% in the url bar)?

Maybe you can also add you about:support for the version you tested? Thanks!

Edit: and do you also see a difference of pointer speed on https://mdn.github.io/dom-examples/pointer-lock/ ?

My setup has 2 monitors (though, this does not affect it); I do not use any scaling (it is 100% by default), also I don't usually use zoom in firefox (unless specifically needed in test process).

I have attached the about:support information from an affected browser session.

The other test page you've linked in your request does not seem to be affected by a similar issue.
Mouse navigation sensitivity appears to be the same in both wayland and xwayland window protocols.

Hm, tested this again and both, https://classic.minecraft.net/ and https://mdn.github.io/dom-examples/pointer-lock/, appear to be affected. Strangly, apparently only when using an actual mouse, not my touchpad. Will look into it.

Greg, I'm a bit stuck on this. Do you see something similar yourself? What confuses me is that things work totally fine for my touchpad but not the mouse. Any ideas?

The MDN example has good speed with both mouse and touchpad for me. Minecraft is slow (too low sensitivity) with the touchpad but fine with the mouse. Weird.

The only thing that's been bothering me is not speed related — non-fullscreen things seem to have some downward drift of the cursor when moving only horizontally, it is only slightly noticeable in the MDN example but way more significant in the "grab and drag a number field" feature in Figma. Maybe that's related to the rounding of the center or something. We should try directly passing the deltas to movementX/Y.

Yeah, I can confirm that. The pointer lock demo feels good speed-wise but drifts vertically when moving horizontally. Minecraft is too slow. This applies to both touchpad and mouse.

Using Chrome from Flatpak (XWayland), the pointer lock demo moves too quickly but Minecraft feels good.

Epiphany on Wayland seems to be using unaccelerated deltas like Firefox used to. The pointer lock demo feels okay but Minecraft is unusably slow.
Epiphany on XWayland is broken.

Arch Linux, GNOME Shell 41.3, scale 2.

Here's some logging where 'PLC' lines are from the GTK nsWindow and the 'cur' lines are from UIEvent::GetMovementPoint:

cur 676,430 last 667,430 delta 9,0
cur 676,345 last 664,344 delta 12,1
cur 676,345 last 664,344 delta 12,1
cur 676,345 last 664,344 delta 12,1
PLC 1329,859 delta 4.937500,0.000000
cur 667,430 last 676,430 delta -9,0
PLC 1329,859 delta 6.753906,0.000000
cur 668,430 last 667,430 delta 1,0
cur 668,345 last 664,344 delta 4,1
cur 668,345 last 664,344 delta 4,1
cur 668,345 last 664,344 delta 4,1
PLC 1329,859 delta 30.132812,0.000000
cur 680,430 last 668,430 delta 12,0
cur 680,345 last 664,344 delta 16,1
cur 680,345 last 664,344 delta 16,1
cur 680,345 last 664,344 delta 16,1
PLC 1329,859 delta 6.496094,0.000000
cur 668,430 last 680,430 delta -12,0

This 1 delta (which seems to be a HiDPI rounding error, doesn't happen to me with Title Bar enabled) that does the drift comes from those extra events that did not come from our relative events. Could it be that we still have absolute events coming too?

Nah, that's not it. The drift is because whatever operations inside Firefox transform the event to remove window offsets are not exactly inverse to + mChromeOffset, causing a rounding error to constantly accumulate :/

I can't really reproduce the Minecraft speed problem. (I said it's too slow with touchpad but.. not really, that's just "controlling first person cameras with a touchpad generally is not good".) Maybe that's actually something in the compositor, not under our control.

Possibly related: bug 1644307

I just started a session with scale-monitor-framebuffer enabled and the speed of the locked pointer got halved. Now Minecraft is extremely slow again.

PS: Using Chrome from Flatpak (XWayland), the browser is now scaled by the compositor, the pointer lock demo moves at the same speed as the pointer and Minecraft feels too slow, but not as slow as Firefox.

Arch Linux, GNOME Shell 41.3, scale 2.

I tested Chromium under Wayland and mouse pointer lock works there as expected. So it's something on Firefox side. I wonder how the actual mouse delta is calculated by layout code because mouse input looks the same on X11 and Wayland.

It really depends on screen scale. I switched screen to 1900x1020 and mouse cursor is the same on X11 and Wayland. We may need to scale both cursor position and perhaps also screen area. When logging refpoint (center) in 4K res, X11 has 1900, 1020 but Wayland ~ 600, 500.

https://hg.mozilla.org/mozilla-central/rev/10f317570e37

I would like to attempt the verification of this fix, but I can't seem to launch Firefox with the Wayland Window Protocol using the original steps.
Is there another way to force-open Firefox with Wayland on Ubuntu 22?

The steps that worked before and no longer work:

1. Open the folder where the build is located.
2. Right-click inside the folder and click "Open in Terminal".
3. To activate Wayland Window Protocol, type in:
   export MOZ_ENABLE_WAYLAND=1
4. To lanch Firefox, type in:
   ./firefox
   Expected: Firefox would launch using the Wayland Window Protocol.
   Actual: It launches Firefox with X11 Window Protocol.

Hm, that should work. Are you maybe not running a Wayland session? You can verify with echo $XDG_SESSION_TYPE (should print wayland).

I don't understand why it does not switch to wayland. Any ideas?

(In reply to Daniel Bodea [:danibodea] from comment #31)

I don't understand why it does not switch to wayland. Any ideas?

See https://linuxconfig.org/wp-content/uploads/2022/01/02-how-to-enable-disable-wayland-on-ubuntu-22-04-desktop.png from https://linuxconfig.org/how-to-enable-disable-wayland-on-ubuntu-22-04-desktop

I have managed to launch Nightly v119.0a1 and Beta v118.0b3 with Wayland Window Protocol in Ubuntu 22.04.
Unfortunately, this issue still occurs. The mouse sensitivity is more than half slower compared to the Chrome browser and the same behavior can be found in the "unfixed" branch v117 (tested Release v117.0) while the issue does not reproduce in xwayland or x11 window protocols.

Forwarding this to Martin.

(In reply to Daniel Bodea [:danibodea] from comment #33)

I have managed to launch Nightly v119.0a1 and Beta v118.0b3 with Wayland Window Protocol in Ubuntu 22.04.
Unfortunately, this issue still occurs. The mouse sensitivity is more than half slower compared to the Chrome browser and the same behavior can be found in the "unfixed" branch v117 (tested Release v117.0) while the issue does not reproduce in xwayland or x11 window protocols.

How do you test the mouse sensitivity? Is there any testcase available?
Thanks.

There isn't a minimal test case for this bug. The reproduction steps are in comment 0. The mouse sensitivity in Minecraft Classic web-game is compared between Firefox in Wayland and Firefox in x11 or Chrome.

The https://classic.minecraft.net is somehow specific.
I used different tescases for locked pointers (https://mdn.github.io/dom-examples/pointer-lock/ for instance) and it was fixed there...not sure why minecraft is so different here.

FTR, Minecraft's mouselook behaves identically in Firefox Nightly on Wayland and Chrome (from Flatpak) on XWayland here.

GNOME Shell 44.4 on Arch Linux, 200% scale, scale-monitor-framebuffer is disabled.