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)
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.
Updated•7 years ago
|
Component: Untriaged → Event Handling
Product: Firefox → Core
Comment 1•7 years ago
|
||
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.
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)
Assignee | ||
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•