high-resolution Xinput scrolling replaced with smooth scrolling between firefox 78 and 91
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: sideskate, Unassigned)
References
(Regression)
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
Steps to reproduce:
Between firefox 78 ESR and 91 ESR, high-resolution Xinput smooth scrolling (e.g. from synaptics) seems to have been replaced with smooth scrolling. This remains even if "mousewheel.system_scroll_override.enabled" is set to false (e.g. preserve system scrolling)
See old bug https://bugzilla.mozilla.org/show_bug.cgi?id=958868 (this is a new bug, as requested)
Actual results:
Scrolling is laggy compared to other Qt or Gtk applications
Expected results:
same scrolling across apps
Incidentally, it does still work correctly in Wayland, or at the very least an awful lot better.
More important, the same issue is still present in 97 as well as nightly.
|
||
Comment 2•3 years ago
|
||
I wonder if it's related to the kinetic scrolling feature (momentum scrolling after a touchpad scroll). Can you try with apz.gtk.kinetic_scroll.enabled set to false in about:config and see if it makes any difference?
Luckily (?) that makes no difference. The problem is that Firefox is using ancient early '90s style wheel events and it's scrolling by "lines". I.e., the behavior is identical to the worst mouse scrollwheel in your possession when you should be seeing (sub)pixel perfect scrolling as it's always been. The original bug report lays it out perfectly; there's really nothing to add to that.
http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-scrolling.html
|
||
Updated•3 years ago
|
|
|
||
Comment 4•3 years ago
|
||
One more thing to try: does running Firefox with MOZ_USE_XINPUT2=1 in the environment help?
That's the ticket! It seems to overrule whichever if statement is slightly off. :-)
Actually on closer look I'm not sure if I was correct or if it's just using significantly smaller "lines". It's not as smooth as other programs but perhaps it never was. I'll have to double check against 78 ESR.
No, I'm not imagining it. Precision definitely seems to be better in 78 than in 97, but that's probably a different issue, if it is an issue.
What's particularly strange is that I also had to use MOZ_USE_XINPUT2=1 with 78, which is not something I ever recall having done previously (and if I had it'd still be in my global environment O.o).
|
|
||
Comment 8•3 years ago
|
||
Glad to hear MOZ_USE_XINPUT2=1 improves things for you. For reference, bug 1207700 tracks turning XInput2 on by default, but as you can see in the comments there we haven't had success at doing so without causing other regressions. At this point, it's probably more realistic to focus on improving Wayland.
(In reply to Frans from comment #7)
No, I'm not imagining it. Precision definitely seems to be better in 78 than in 97, but that's probably a different issue, if it is an issue.
If 97 behaves noticeably worse for you than 78 with other things being equal, and you're interested in helping get to the bottom of it, you could run the mozregression tool to find what change in that version range regressed the behaviour.
It's not necessarily clear if it's worse or just different. If it wasn't on purpose then I suppose it's probably worse. I can try to investigate but that tool doesn't seem to be very helpful because it wants me to try things one by one?
MOZ_USE_XINPUT2=1 mozregression -g 78 -b 91
0:01.06 INFO: Using date 2021-07-12 for release 91
0:02.00 INFO: Using date 2020-06-01 for release 78
0:05.41 INFO: Testing good and bad builds to ensure that they are really good and bad...
0:05.42 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2020/06/2020-06-01-21-42-28-mozilla-central/firefox-79.0a1.en-US.linux-x86_64.tar.bz2
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): skip
0:50.30 INFO: You can not skip this build.
I.e., as far as trying to find out where it broke that's utter madness. Broken in between 78 and 91 = try 84 (or 85, or something in between), if good try 87, if bad try 81, and so forth. It doesn't mean trying every single build one by one. Plus as you can see it refuses to skip broken builds that aren't broken in a relevant sense. (79.0a1 crashes on startup)
But that aside.
|
|
||
Comment 10•3 years ago
|
||
(In reply to Frans from comment #9)
I.e., as far as trying to find out where it broke that's utter madness. Broken in between 78 and 91 = try 84 (or 85, or something in between), if good try 87, if bad try 81, and so forth. It doesn't mean trying every single build one by one.
What you're describing is a bisection, and that's exactly what mozregression does. It just starts by verifying that the build at the beginning of the initial range is "good" and the build at the end of the range is "bad", that's why you can't skip those. Verifying that those two builds behave as expected is important to be sure you're doing a valid bisection; without that, it has happened that e.g. the issue doesn't reproduce in the build at the end of the range in a clean profile (e.g. because it requires some configuration not present in a clean profile), and then you waste your time doing a useless bisection.
|
||
Comment 11•3 years ago
|
||
So you're saying that if I lie to it and say 78.0b1 or something like that, it'll ask me about 78 so I can avoid it being stupid about the fact that 79.0a1 is broken?
|
|
||
Comment 12•3 years ago
|
||
Ah, you mean the build at the beginning of the range crashes on startup? If so, you can use a different nearby build instead. It accepts dates, so you can try e.g. mozregression -g 2020-05-31 -b 91
|
|
||
Comment 13•3 years ago
|
||
Well, as it turns out even though 78 ESR runs like a charm all the nightly builds this mozregression tool manages to pull in prior to 80-something don't seem to work?
On the plus side, in the meantime I can confirm that using MOZ_USE_XINPUT2=1 mozregression -g 84 -b 91 is successful on both accounts. 84 is still the same as 78.
|
|
||
Comment 14•3 years ago
|
||
Okay, once past the initial bad experience with the tool it was quite helpful to not only quickly narrow down the date but even the exact commit:
|
|
||
Comment 15•3 years ago
|
||
Which also shows that setting mousewheel.system_scroll_override.enabled to false restores the original behavior.
It's probably worth pointing out that I do enjoy that setting with a traditional scroll wheel. It's the decreased precision from newer scrolling methods that makes it feel like a regression.
|
|
||
Comment 16•3 years ago
|
||
(In reply to Frans from comment #14)
Okay, once past the initial bad experience with the tool it was quite helpful to not only quickly narrow down the date but even the exact commit:
Thanks!
Needinfo to Emilio as a heads-up; not sure if there's any action we want to take here.
|
||
Comment 17•3 years ago
•
|
||
That commit only flips mousewheel.system_scroll_override.enabled=true on Linux, so I'm confused about how comment 0 mentions that it's not fixed by flipping it to false, but comment 15 does.
Anyways, can you confirm that if you use Wayland that setting doesn't have an effect on touchpad / trackpad scrolling? I believe with X11, even with MOZ_USE_XINPUT2=1, we can't differentiate between trackpad / touchscreen scrolling and mousewheel scrolling...
|
||
Comment 18•3 years ago
|
||
Set release status flags based on info from the regressing bug 1715513
|
|
||
Comment 19•3 years ago
|
||
It might be relevant to note that I did my tests with EmulateWheelButton. Additionally, proper support for less horrible scrollwheels was recently added to libinput. From my perspective the only thing that matters is that all of these are (vastly) superior to traditional scroll wheels but perhaps it's different on the implementation side.
The setting doesn't seem to affect scrolling with a touchpad or touchscreen on Wayland but I'll have to double check that in X11.
|
|
||
Updated•3 years ago
|
|
|
||
Comment 20•3 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
|
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
Description
•