Mouse wheel without modifiers stopped working on nightly 2022-10-28
Categories
(Core :: Panning and Zooming, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox108 | --- | affected |
People
(Reporter: maciej.wakula+github, Unassigned)
References
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0
Steps to reproduce:
Currently using nightly 108.0a1
After start, auto-update of nightly and restart I noticed that my mouse wheel is no longer working (with no modifiers at least).
Steps to reproduce:
Create a new profile: firefox -p myAwesomeProfileName
open any page (ex. start page or about:config)
use mouse wheel to scroll
ensure that mousewheel.default.action is set to default (1)
set mousewheel.with_control.action to 1 and test if mouse wheel scrolls with control pressed
Notice recent changes https://hg.mozilla.org/mozilla-central/rev/fa38a436bc293485a9185e11a1c7b974f4568b49
My browser version information points to revision https://hg.mozilla.org/mozilla-central/rev/18c629b7b3b551361eb9da735294359a318b293c
Actual results:
Default (no modifiers) scroll does not work.
Control + scroll scrolls properly.
Expected results:
Both default scroll and control+scroll should work when set to 1.
Reporter | ||
Comment 1•2 years ago
|
||
I tried the "troubleshooting mode" which disabled all the plugins and then it works fine.
Notice that I tried also a fresh profile and this did not work. Neither worked when I manually disabled all the plugins.
![]() |
||
Comment 2•2 years ago
|
||
According to comment#0,
the regressor seems to be
fa38a436bc293485a9185e11a1c7b974f4568b49 Chris Peterson — Bug 1781960 - Scroll on Cmd or Ctrl + mousewheel on macOS. r=masayuki
![]() |
||
Updated•2 years ago
|
![]() |
||
Updated•2 years ago
|
Comment 3•2 years ago
|
||
(In reply to Alice0775 White from comment #2)
According to comment#0,
the regressor seems to be
fa38a436bc293485a9185e11a1c7b974f4568b49 Chris Peterson — Bug 1781960 - Scroll on Cmd or Ctrl + mousewheel on macOS. r=masayuki
This commit was backed out on autoland before merging to mozilla-central, and has not yet relanded, so I don't think it can be the regressor for a bug observed in a nightly build.
Comment 4•2 years ago
|
||
(In reply to maciej.wakula+github from comment #1)
I tried the "troubleshooting mode" which disabled all the plugins and then it works fine.
Notice that I tried also a fresh profile and this did not work. Neither worked when I manually disabled all the plugins.
The same was observed in bug 1798014, suggesting it may be the same issue.
You could try the workaround in bug 1798014 comment 7, or the alternative workaround suggested in bug 1798014 comment 9.
(If the alternative workaround works, that explains why "troubleshooting mode" avoids the issue: in addition to disabling addons, it disables hardware acceleration.)
Comment 5•2 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Comment 6•2 years ago
|
||
Maciej, do you have Symantec Endpoint Protection installed?
Comment 7•2 years ago
|
||
Closing the bug as a duplicate. We are tracking this issue in Bug 1798014. It would still be nice to know if Maciej is using Symantec Endpoint Protection though
Reporter | ||
Comment 8•2 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
Maciej, do you have Symantec Endpoint Protection installed?
I do NOT have Symantec Endpoint Protection.
First workaround (security.sandbox.gpu.level=0) worked so this is a duplicate.
Than you!
Description
•