[wayland][weston] Input behaves strangely (fast) on webgl sites.
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: barz621, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
Run firefox on weston. Go to www.justbuild.lol or www.3daimtrainer.com and try to play.
Actual results:
On fullscreen the input is extremely fast (like using insanely high DPI)
Expected results:
Input should behave normaly. Same speed as browsing.
|
||
Updated•5 years ago
|
Hi,
please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem.
If you still have the issue please create a new profile, you have the steps here:https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager
Lastly test if the issue is reproducible in safe mode, here is a link that can help you:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
Regards
I was not able to reproduce this, but in my case i tested it on ubuntu 18.04.02 LTS 64bit with Firefox Release 68.0.1
speed was normal as playing a shooter videogame.
(In reply to Pablo from comment #2)
I was not able to reproduce this, but in my case i tested it on ubuntu 18.04.02 LTS 64bit with Firefox Release 68.0.1
speed was normal as playing a shooter videogame.
I am on Arch with everything latest stable. No idea what the weston version is on Ubuntu. Might be the cause.
|
||
Comment 4•5 years ago
|
||
Reproduced this behavior under the following conditions:
uname -a is Linux hostname 5.3.0-1-MANJARO #1 SMP Sun Jul 28 22:03:50 UTC 2019 x86_64 GNU/Linux for all tests. (Manjaro is an Arch-based distribution.)
- Firefox Developer Edition 69.0b11
- Firefox Nightly 70.0a1 (2019-08-09)
- SwayWM 1.1.1
- Gnome shell 3.32.2
The behavior is present in any permutation of these, on both sites the OP listed, as well as others. Here's a video of the behavior. The corresponding input is my moving my mouse slowly and smoothly to the right. Note how the game turns the opposite direction to my mouse movement.
The bug only appears to happen when a webgl context captures the mouse. This game shows an interesting edge case. After pressing the button to run the game, if you don't click on the canvas, the game still registers mouse movement as long as it's over the frame. Only once you click in the frame and the game captures the mouse does the bug appear. Here is another video that demonstrates the behavior.
|
|
||
Comment 5•4 years ago
|
||
This is a duplicate of Bug 1551092 - wrong mouse pointer lock.
Description
•