1748921 - [x11/xwayland] Firefox on Linux scrolls much further than Chrome on Linux with touchpad (and further than Firefox/Chrome on other platforms)

Status: NEW

(Core :: Widget: Gtk, defect)

Description

[Daniel Holbert [:dholbert]]

[spinning this off of bug 1671067]

STR:

1. Load attached testcase
2. Touch the extreme bottom edge of your touchpad with two fingers (or the top, depending on how your scroll direction is set up)
3. Drag your fingers to the opposite edge of your touchpad, and see how far this causes you to scroll (by watching your scrollbar)

ACTUAL RESULTS:
I scroll to the very end of the page (or close to it), ~5800px.

EXPECTED RESULTS:
I should perhaps not scroll so much.

My "ACTUAL RESULTS" here are from Firefox Nightly 97 on Ubuntu 21.10.

For comparison: Chrome in the same environment (Ubuntu) scrolls about halfway down the page when I perform the STR -- so, it's about half as responsive.

On Windows 11 (on the same machine) and on Mac, Firefox Nighlty as well as Chrome scroll ~1/6th of the way down the page when I perform the STR

So, putting that another way: for touchpad scrolling at least...

• Firefox-on-Ubuntu seems to scroll about ~2x as far as Chrome-on-Ubuntu
• Firefox-on-Ubuntu seems to scroll about ~6x as far as Firefox or Chrome on other operating systems (Windows 11 & Mac)
  ...and this discrepancy is a bit concerning.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

That's fairly concerning. I haven't seen this generally, but two things:

• Does mousewheel.system_scroll_override.enabled change this?
• Is this on wayland (MOZ_ENABLE_WAYLAND=1) or X11? if on X11, does MOZ_USE_XINPUT2=1 help / change behavior?

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Looks like I forgot to attach a testcase -- here it is (just a 5800px-tall page).

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

That's fairly concerning. I haven't seen this generally, but two things:

• Does mousewheel.system_scroll_override.enabled change this?

Yes, it does! If I toggle that to false, then the STR only get me halfway down the page (which matches Chrome's behavior).

• Is this on wayland (MOZ_ENABLE_WAYLAND=1) or X11? if on X11, does MOZ_USE_XINPUT2=1 help / change behavior?

Details below, but briefly: I think my Firefox session is in X11 mode, and MOZ_USE_XINPUT2 doesn't change anything AFAICT; and if I opt in to using Firefox in wayland mode, then I get a new and different behavior (scrolling slightly less far but still pretty far).

More details:

• MOZ_USE_XINPUT2=1 does not seem to change behavior for me. (If I start Firefox with MOZ_USE_XINPUT2=1 firefox, my touchpad-swipe still scrolls the full height of the page, or half the height of the page if I toggle the aforementioned mousewheel pref.)
• I am using Wayland at an OS level (i.e. echo $XDG_SESSION_TYPE prints wayland, and I do see Window Protocol xwayland in about:support).
• ...however, I do not have the MOZ_ENABLE_WAYLAND environmental variable explicitly set, which I think means my answer is "no, not on wayland" for the purposes of your question.
• If I adjust my STR to actually be "on wayland", i.e. if I start Firefox with MOZ_ENABLE_WAYLAND=1 firefox, then a full-touchpad-swipe takes me ~80% of the way down the page (intermediate between the Chrome results, and the stock-Firefox results, which take me ~50%/100%). Also, the mousewheel.system_scroll_override.enabled pref seems to stop making a difference (no change in results when I toggle that pref) under this opted-in-to-wayland configuration.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

(In reply to Daniel Holbert [:dholbert] from comment #3)

• I am using Wayland at an OS level (i.e. echo $XDG_SESSION_TYPE prints wayland, and I do see Window Protocol xwayland in about:support).
• ...however, I do not have the MOZ_ENABLE_WAYLAND environmental variable explicitly set, which I think means my answer is "no, not on wayland" for the purposes of your question.

Yeah, if you were using wayland you'd see Window Protocol: wayland instead in about:support.

• If I adjust my STR to actually be "on wayland", i.e. if I start Firefox with MOZ_ENABLE_WAYLAND=1 firefox, then a full-touchpad-swipe takes me ~80% of the way down the page (intermediate between the Chrome results, and the stock-Firefox results, which take me ~50%/100%). Also, the mousewheel.system_scroll_override.enabled pref seems to stop making a difference (no change in results when I toggle that pref) under this opted-in-to-wayland configuration.

I think that's the expected behavior. The system_scroll_override pref is only expected to enlarge mousewheel ticks, not touchpad / trackpad stuff. My guess is that on wayland you are hitting this code for your trackpad:

https://searchfox.org/mozilla-central/rev/a81c30e422208931d977490a1d17b70c862a684f/widget/gtk/nsWindow.cpp#4573

And you're falling through on X11, is that right? That shouldn't be the case with MOZ_USE_XINPUT2=1 (behavior should match Wayland...), but anyways...

If that's happening, mind printing source and the deltas? Something like printf("delta = %f,%f source=%d\n", aEvent->delta_x, aEvent->delta_y, source); My guess is that the deltas would be fractional numbers of different magnitude, but the source would be still 0 (mouse), and we have no way to differentiate actual mouse input for a trackpad :/

Using "it's a fractional number" might work, but we'd need to at least not use it on wayland because of https://bugs.kde.org/show_bug.cgi?id=438326

Comment 5

[Daniel Holbert [:dholbert]]

In my default configuration (i.e. with about:support showing Window Protocol xwayland), with a local debug+opt build, my touchpad scrolling just uses these cases in nsWindow::OnScrollEvent:

    case GDK_SCROLL_UP:
      wheelEvent.mDeltaY = wheelEvent.mLineOrPageDeltaY = -3;
      wheelEvent.mWheelTicksY = -1;
      break;
    case GDK_SCROLL_DOWN:
      wheelEvent.mDeltaY = wheelEvent.mLineOrPageDeltaY = 3;
      wheelEvent.mWheelTicksY = 1;
      break;

i.e. I don't hit the code that you linked (since that code is inside the GDK_SCROLL_SMOOTH case).

If I run with MOZ_USE_XINPUT2=1, then I do hit the code that you linked, and I get values like this when scrolling down the page (from the printf you suggesetd, which I inserted just before the source==touchscreen/touchpad check). Note that source=0 which means GDK_SOURCE_MOUSE here, so we jump over the touchscreen/touchpad-specific clause that you linked.

delta = 0.000000,1.921875 source=0
delta = 0.000000,1.683594 source=0
delta = 0.000000,1.343750 source=0
delta = 0.000000,1.164062 source=0
delta = 0.000000,0.625000 source=0
delta = 0.000000,0.429688 source=0
delta = 0.000000,0.300781 source=0
delta = 0.000000,0.195312 source=0
delta = 0.000000,0.128906 source=0
delta = 0.000000,0.203125 source=0
delta = 0.000000,0.113281 source=0
delta = 0.000000,0.144531 source=0
delta = 0.000000,0.031250 source=0
delta = 0.000000,0.105469 source=0

If I run with MOZ_ENABLE_WAYLAND=1, then I get output like the following (notably with source=6 which is GDK_SOURCE_TOUCHPAD).

delta = 0.000000,0.570312 source=6
delta = 0.000000,0.398438 source=6
delta = 0.000000,0.511719 source=6
delta = 0.000000,0.226562 source=6
delta = 0.000000,0.128906 source=6
delta = 0.000000,0.023438 source=6
delta = 0.000000,0.121094 source=6
delta = 0.000000,0.218750 source=6
delta = 0.000000,0.421875 source=6
delta = 0.000000,0.910156 source=6
delta = 0.000000,1.089844 source=6
delta = 0.000000,0.527344 source=6
delta = 0.000000,0.121094 source=6
delta = 0.000000,0.144531 source=6
delta = 0.000000,0.031250 source=6
delta = 0.000000,0.097656 source=6
delta = 0.000000,0.000000 source=6

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Ok, so I took a look on my laptop and well, I can repro, and I have good and bad news:

• Good news: Ubuntu and Fedora nowadays ship Wayland-enabled Firefox so they are not affected by this.
• Good news: Even though on XWayland Xinput2 doesn't behave as expected, on regular X11 it does, so bug 1207700 would fix this for X11 users.
• Bad news: bug 1207700 seems stalled, and I have no idea how to properly detect touchpad scroll in non-XInput2.

Martin, do you know if the fixes that X11 needed to make bug 1207700 feasible ever landed on GTK3? That is, can we retry landing that?

Comment 7

[Martin Stránský [:stransky] (ni? me)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

Martin, do you know if the fixes that X11 needed to make bug 1207700 feasible ever landed on GTK3? That is, can we retry landing that?

AFAIK Gtk3/X11 backend is not developed/fixed any more so I think this is still broken.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #3)

[...] if I opt in to using Firefox in wayland mode, then I get a new and different behavior (scrolling slightly less far but still pretty far).

One followup point on this -- my above-quoted text sounded like Wayland would be a slight improvement, but I've found that this bug is way-more-annoying with Wayland enabled (and it is now enabled by default in Nightly/early-beta, per bug 1749174), due to a Wayland-specific "kinetic scroll" feature that we seem to have.

With Wayland enabled, it looks like touchpad-scrolling triggers a kinetic after-effect, where the scroll continues gliding even after you release your fingers. As a result of this bug here (where we're over-estimating the velocity of touchpad scrolls, including with Wayland to a slightly lesser extent), this kinetic glide ends up scrolling extremely far, with just a gentle brush of my touchpad.

This makes touchpad-scrolling kind of unusable on my machine, unfortunately, unless I'm very careful to leave my fingers on the touchpad to prevent the kinetic-scroll "fling" after-effect.

Comment 9

[Daniel Holbert [:dholbert]]

(Looks like I can disable the kinetic-scroll "fling" behavior by setting apz.gtk.kinetic_scroll.enabled to false; that seems to be a workaround for the issue discussed in comment 8. That pref-controlled behavior is here in the GDK_SCROLL_SMOOTH case, which is a codepath that I wasn't hitting by default, per comment 5, until we turned on Wayland.)

Comment 10

[Darkspirit]

(In reply to Daniel Holbert [:dholbert] from comment #8)

(and it is now enabled by default in Nightly/early-beta, per bug 1749174),

until we turned on Wayland.

It has been enabled in Stable downstream for ~a year before it has been enabled in Nightly and Beta.

Comment 11

[eeshugerman]

(In reply to Daniel Holbert [:dholbert] from comment #8)

One followup point on this -- my above-quoted text sounded like Wayland would be a slight improvement, but I've found that this bug is way-more-annoying with Wayland enabled (and it is now enabled by default in Nightly/early-beta, per bug 1749174), due to a Wayland-specific "kinetic scroll" feature that we seem to have.

With Wayland enabled, it looks like touchpad-scrolling triggers a kinetic after-effect, where the scroll continues gliding even after you release your fingers. As a result of this bug here (where we're over-estimating the velocity of touchpad scrolls, including with Wayland to a slightly lesser extent), this kinetic glide ends up scrolling extremely far, with just a gentle brush of my touchpad.

This makes touchpad-scrolling kind of unusable on my machine, unfortunately, unless I'm very careful to leave my fingers on the touchpad to prevent the kinetic-scroll "fling" after-effect.

Is it really the same bug on Wayland? (Sorry if that's obvious, I didn't follow the discussion above too closely). If so, can we remove the [x11/xwayland] tag from the name of this ticket so it's easier for folks to find? If not, I suppose we should open a new ticket?

If I may share my two cents: I've been dealing with what I perceive as way-too-fast touchpad scrolling in Firefox ever since I started using MOZ_ENABLE_WAYLAND=1 about a year ago. For me, the "fling" effect itself is a must-have (will be especially nice once hold gestures make their way up the stack, but I digress). My fix/workaround has been to reduce mousewheel.default.delta_multiplier_y from the default 100 to 30 or so. This works well until I switch to a mouse and try to scroll with the wheel, which is now way too slow...

But wait -- this just in -- in the process of writing this comment, I just found the missing piece to the workaround: in addition to the mousewheel.default.delta_multiplier_y tweak described above, also increase mousewheel.min_line_scroll_amount from the default 5 to about 100. With these two tweaks in place, scrolling feels right with both mousewheel and touchpad.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

I'd say let's file a new issue if Wayland scrolling is too fast. The root causes are different, on X11 we can't even differentiate touchpad vs. other scrolling sources.

Comment 13

[eeshugerman]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)

I'd say let's file a new issue if Wayland scrolling is too fast. The root causes are different, on X11 we can't even differentiate touchpad vs. other scrolling sources.

Done: https://bugzilla.mozilla.org/show_bug.cgi?id=1752862

Comment 14

[Daniel Holbert [:dholbert]]

Thanks!