Open Bug 1420445 Opened 7 years ago Updated 2 years ago

Pointerlock limited, movement rapid and unpredictable

Categories

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

57 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: broughton_g182, Unassigned)

References

Details

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

Steps to reproduce:

Using Pointerlock on any canvas on Fedora Linux 25, fullscreen or not, on firefox 53, 57 and chromium, multiple websites.


Actual results:

Mouse movement limited beyond a certain point, would jump to centre occasionally for a single frame then jump back. The movementX/Y properties for the mouse movement event representing mouse deltas reflected this, had a lower and upper bound beyond which they would not go any further. Many first person shooter type web apps seem to get stuck staring vertically upwards or down, with mouse movement causing extremely rapid rotation. Under Windows 10 same sites no such problem.


Expected results:

Mouse movement not limited, so for example a first person perspective game, one could continually move the mouse to the left and look that way. The movementX/Y should smoothly reflect mouse movement/deltas.
Component: Untriaged → Event Handling
Product: Firefox → Core
Could it be e10s related as https://bugzilla.mozilla.org/show_bug.cgi?id=1417702#c1?

Hi George,
If you have a few minutes to spare:

1) Go to about:config.
2) Toggle browser.tabs.remote.autostart *off*.
3) Restart the browser, and verify that about:support says 0/1 (Disabled) for Multiprocess Windows.
4) Try to reproduce and report back.
Thanks.
Flags: needinfo?(broughton_g182)
Priority: -- → P2
See Also: → 1417702
Thanks for replying. Unfortunately I think that bug is unrelated. browser.tabs.remote.autostart was already off, and MultiProcess Windows was enabled, however I turned browser.tabs.remote.autostart.2 from on to off, restarted, which changed MultiProcess Windows to 0/1 Disabled. 

The bad news is it's still happening. Unlike the bug you linked to, this is also happening in version 53, as well as 57 (and also chromium....). 

If I monitor the MovementX and MovementY, there is no resetting, it is returning an absolute value. Moving the mouse to the left, MovementX dropped all the way down to -683, to the top movementY shows -352, on the right movementX 682, and at the bottom 351. Beyond these values my the pointerlock stops scrolling/firing events. At these points the mouse is at the edge of the window (the screen res is 1366*768). Note the vertical height is 703, my taskbar is at the top of the screen, if the mouse (despite pointer lock trying to hide it) enters this, it stops firing events.

Now that I think about it, assuming for whatever reason movementX/Y are returning absolute values instead of deltas, that explains the rapid rotations and staring vertically up/down in first person perspectives. Based on it also being present in chromium too, I wonder if it is a problem with an underlying system library. 

The OS is stock Fedora Workstation 25. If you want any library information just let me know what you need/how to get it. Thanks
Flags: needinfo?(broughton_g182)
Component: Event Handling → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.