MouseEvent movementX and movementY wrong after requestPointerLock() when display scale is different from 100%
Categories
(Core :: Widget: Win32, defect, P2)
Tracking
()
People
(Reporter: jmfgalvao, Unassigned)
References
Details
(Whiteboard: [win:sizing])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0
Steps to reproduce:
OS: Windows 10 Education, Build 19042.1466
Browser: Firefox 96.0.2 (64-bit)
Display: 3840x2160, scale set to 150%
1 - Set the Windows display scale to 150% in Settings > Display > Scale and layout.
2 - Go to https://mdn.github.io/dom-examples/pointer-lock/
3 - Click on the black canvas area
It depends on the browser's window current size, resizing it sometimes makes the issue appear/disappear, so it is not 100% reproducible, but it happens fairly often.
Actual results:
The red ball starts to slowly move down without moving the mouse.
This is caused because the MouseEvent movementY is returning 1.
Expected results:
The red ball should not move if the mouse is not moving.
The MouseEvent movementY should return 0.
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•1 month ago
|
Comment 2•1 month ago
|
||
There are various changes in pointer lock, and I think this is fixed by bug 1255338.
Feel free to reopen or file a new bug if you still see the issue.
I am unable to reproduce it anymore with build 152.0.2 (which I believe does not include the fix), so the bug might be dormant somewhere, hopefully 1255338 fixes the underlying cause.
Comment 4•1 month ago
|
||
The demo page requests pointerLock with unadjustedMovement option, so the issue could be fixed after we support that in bug 2037802.
If you could help to verify with disabling the support of unadjustedMovement, it would be nice, so that we could know whether the bug 1255338 helps.
To disable the support of unadjustedMovement, you need set dom.pointer-lock.unadjusted-movement.enabled to false in about:config before loading the test page.
(In reply to Edgar Chen [:edgar] from comment #4)
If you could help to verify with disabling the support of unadjustedMovement, it would be nice
Disabling it had no effect (i.e. the bug is still not reproducible), but...
The demo page requests pointerLock with
unadjustedMovementoption, so the issue could be fixed after we support that in bug 2037802.
It seems that that example itself changed meanwhile, which might actually be what is hiding the bug:
https://github.com/mdn/dom-examples/pull/198/changes
I will check the current Firefox behavior with the old version of the example, before those changes happened.
Unfortunately I cannot reproduce the bug. I tried with the original example before those changes, and even reverted back to Firefox 96.0.2 and still I cannot reproduce it.
This is one of those bugs that solved itself and the cause will remain a mystery.
Comment 7•1 month ago
|
||
Thanks for all your help!
Description
•