1752862 - [wayland] Firefox on Linux scrolls much further than Chrome on Linux with touchpad (and further than Firefox/Chrome on other platforms)

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[eeshugerman]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

1. Run Firefox on Wayland with MOZ_ENABLE_WAYLAND=1
2. Load a "tall" (ie with room to scroll) page such as this one
3. Use the touchpad (with two fingers) to scroll
4. Observe scrolling speed

Actual results:

Touchpad scrolling speed feels very fast -- considerably faster than in other browsers: roughly twice as fast as GNOME Web, and maybe 1.5x as fast as in Chrome (which, on my machine at least, doesn't do kinetic scrolling, so the difference feels even greater).

Expected results:

Touchpad scrolling speed "feels right" / is in line with other apps.

Comment 1

[eeshugerman]

A couple more notes...

There is a corresponding ticket for x11/xwayland. I'm opening this new ticket for Wayland per Emilio's suggestion:

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.

I've found that if I set mousewheel.default.delta_multiplier_y to ~40, touchpad and mousewheel.min_line_scroll_amount to ~100, scrolling feels about right with both touchpad and mouse wheel.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Daniel could also repro this, so marking as confirmed based on that. I'd be curious to see what the raw deltas are for your wheel events. I think I have a device that might repro this, I can try to figure out something...

Comment 3

[Emilio Cobos Álvarez (:emilio)]

I can confirm that touchpad in my laptop also scrolls quite faster than GNOME web for the same page...

Here's some relevant WebKitGTK code. I don't understand either why this Firefox code is using PANDELTA_PAGE. The deltas are supposed to be pixels aren't they?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Apparently not: https://gitlab.gnome.org/GNOME/gtk/blob/c734c7e9188b56f56c3a504abee05fa40c5475ac/gtk/gtkrange.c#L3063-3074

So what gnome-web does apparently is using the gtk deltas as percent-of-a-wheel-tick, and use that as a precise pixel delta: https://webkit-search.igalia.com/webkit/rev/215039ef09d6bfd6e088175bfe30788d95b9705d/Source/WebKit/Shared/gtk/WebEventFactory.cpp#265-296

Comment 5

[Emilio Cobos Álvarez (:emilio)]

So GTK in other places takes the deltas as percent-of-wheel-scroll: https://gitlab.gnome.org/GNOME/gtk/-/blob/c734c7e9188b56f56c3a504abee05fa40c5475ac/gtk/gtkeventcontrollerscroll.c#L259-334

Greg, do you know why did you choose one approach over the other? I personally don't mind the current behavior, but it seems others do so I want to know the reasoning behind our current behavior.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1752862 - Allow some customization of the GTK kinetic scroll parameters. r=botond,myfreeweb

This doesn't change behavior by default, but should allow users to tweak
them and provide feedback as to which scroll speed is better for them.

It seems for some people at least the current speed is too much. The
"pixel" mode I implemented should behave exactly like GNOME web, in
terms of scroll speed.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Daniel, reporter: When this lands, could you provide feedback on:

• Scrolling with apz.gtk.kinetic_scroll.mode=2: This behavior should pretty closely / exactly match GNOME web. If not comfortable enough, try a lower or higher apz.gtk.kinetic_scroll.pixel_mode_multiplier.

• Scrolling with apz.gtk.kinetic_scroll.mode=0 (or 1): This behavior should be the current one. Try a lower apz.gtk.kinetic_scroll.page_mode_multiplier (like 0.5, 0.4, 0.3...) and report which one feels better perhaps?

Comment 8

[Val Packett]

why did you choose one approach over the other?

I just did what was straightforward to do and it did feel very similar to native GTK applications.

I guess it does make sense that people would compare against other browsers specifically, so maybe the WebKitGTK-style behavior should even be the default…

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Thanks for the context!

Comment 10

[Emilio Cobos Álvarez (:emilio)]

(I'd say we should consider changing the default in a separate bug, once we've gotten some feedback from existing users, unless you feel very strongly about it? I honestly don't mind either behavior)

Comment 11

[Val Packett]

I honestly don't mind either behavior

Same.

---

BTW, see also / duplicate(?): bug 1610477, bug 1674218

Comment 12

[eeshugerman]

(In reply to greg v [:unrelentingtech/myfreeweb] from comment #8)

why did you choose one approach over the other?

I just did what was straightforward to do and it did feel very similar to native GTK applications.

I guess it does make sense that people would compare against other browsers specifically, so maybe the WebKitGTK-style behavior should even be the default…

This prompted me to try scrolling on some other GTK apps (besides Web) and yeah, touchpad scrolling does feel similar to Firefox (without my about:config tweaks) -- too fast, touchy. I never gave it much thought because the only GTK app I do much scrolling in is Firefox.

So I guess this might be more of a GTK/Wayland issue. Or just a personal preference :). the issue is that this isn't globally configurable on Wayland.

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

Daniel, reporter: When this lands, could you provide feedback on:

• Scrolling with apz.gtk.kinetic_scroll.mode=2: This behavior should pretty closely / exactly match GNOME web. If not comfortable enough, try a lower or higher apz.gtk.kinetic_scroll.pixel_mode_multiplier.

• Scrolling with apz.gtk.kinetic_scroll.mode=0 (or 1): This behavior should be the current one. Try a lower apz.gtk.kinetic_scroll.page_mode_multiplier (like 0.5, 0.4, 0.3...) and report which one feels better perhaps?

Yes, I'd be glad too! How do you suggest I track it? Should I expect it in Developer Edition any time soon?

Comment 13

[Val Packett]

@emilio just tested the patch, you need to multiply the pixel mode multiplier by the HiDPI scale factor (mWindowScaleFactor), otherwise it's 2x slower than WebKitGTK on my 2x display.

(BTW I cannot even comment on the phab revision because: phab-bot changed the edit policy from "Custom Policy" to "Restricted Project (Project)".)

---

this isn't globally configurable on Wayland

Ask your compositor's developers :) In Wayfire we have an adjustable global multiplier for all touchpad scroll deltas.

Comment 14

[eeshugerman]

(In reply to greg v [:unrelentingtech/myfreeweb] from comment #13)

@emilio just tested the patch, you need to multiply the pixel mode multiplier by the HiDPI scale factor (mWindowScaleFactor), otherwise it's 2x slower than WebKitGTK on my 2x display.

(BTW I cannot even comment on the phab revision because: phab-bot changed the edit policy from "Custom Policy" to "Restricted Project (Project)".)

---

this isn't globally configurable on Wayland

Ask your compositor's developers :) In Wayfire we have an adjustable global multiplier for all touchpad scroll deltas.

Noted, thanks! Looks like there is some progress on this over here in GNOME land.

Comment 15

[Botond Ballo [:botond]]

Potentially related: bug 1175251

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Thanks, fixed.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e635157e4111
Allow some customization of the GTK kinetic scroll parameters. r=botond

Comment 20

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/e635157e4111

Comment 21

[Daniel Holbert [:dholbert]]

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

Daniel, reporter: When this lands, could you provide feedback on:

(nit: I assume you meant s/mode/delta_mode/ in all the pref names; they seem to exist under the delta_mode pref names. Aha, I guess this was a rename in response to a review comment, which makes sense.)

• Scrolling with apz.gtk.kinetic_scroll.mode=2: This behavior should pretty closely / exactly match GNOME web. If not comfortable enough, try a lower or higher apz.gtk.kinetic_scroll.pixel_mode_multiplier.

This feels much better than the default! We still scroll a bit more aggressively than Gnome Web (epiphany), but I can actually do a kinetic scroll of a few line-heights with a gentle brush of the touchpad (which I can't do in the default scrolling mode).

RE the multiplier's value (under this delta_mode=2 configuration): the default multiplier has a little bit more velocity/distance than Gnome Web, but not too much. Maybe 20.0 instead of 40.0 is a bit better? I'm not sure.

One thing I'm noticing, though: in Nightly, a good fraction of my attempted kinetic-drags end up being "non-kinetic" -- they just scroll a few line-heights and then stop abruptly. I think this happens more often under this delta_mode=2 configuration (vs the default), though I'm not 100% sure. I can trigger this issue very reliably by "reversing" an in-progress kinetic scroll, e.g. swipe to scroll down and wait a half-second and then (while the scroll is gliding) swipe in the opposite direction. I would expect this to produce a reversed kinetic scroll (in the direction of my last swipe), but instead it just halts the scroll that was happening and scrolls back a little bit.

• Scrolling with apz.gtk.kinetic_scroll.mode=0 (or 1): This behavior should be the current one. Try a lower apz.gtk.kinetic_scroll.page_mode_multiplier (like 0.5, 0.4, 0.3...) and report which one feels better perhaps?

The default behavior feels like it scrolls too far, but 0.3 feels pretty-natural to me.

Comment 22

[eeshugerman]

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

Daniel, reporter: When this lands, could you provide feedback on:

• Scrolling with apz.gtk.kinetic_scroll.mode=2: This behavior should pretty closely / exactly match GNOME web. If not comfortable enough, try a lower or higher apz.gtk.kinetic_scroll.pixel_mode_multiplier.

• Scrolling with apz.gtk.kinetic_scroll.mode=0 (or 1): This behavior should be the current one. Try a lower apz.gtk.kinetic_scroll.page_mode_multiplier (like 0.5, 0.4, 0.3...) and report which one feels better perhaps?

Just tried this out. I largely concur with Daniel: mode=2 is a significant improvement over the current default, but with pixel_delta_mode_multiplier=40 it's still a bit fast -- 25 feels about right to me. For mode=0, page_delta_mode_multiplier=0.4 feels about right.

Comment 23

[Simonas Kazlauskas [:nagisa/:simukis]]

Can confirm, mode 2 is definitely an improvement. Though now that scrolling is somewhat slower, all the stutters that come up routinely have also become much more prominent.

Comment 24

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

As stated above, mode 2 is significantly better and more user-friendly than 0, which was way too fast for comfort. Removing the qe-verify flag for now.

Comment 25

[Oliver Ford]

Agree delta_mode=2 (as it's now called) is much better. Can it be equivalently slowed down while kinetic_scroll.enabled=false though?

I dislike the scroll continuing after I've stopped, but enabling it is the only way I've found of getting a sensible scroll speed when I do want it to be scrolling.

Thanks,

Comment 26

[Botond Ballo [:botond]]

(In reply to Oliver Ford from comment #25)

Agree delta_mode=2 (as it's now called) is much better. Can it be equivalently slowed down while kinetic_scroll.enabled=false though?

With kinetic_scroll.enabled=false, touchpad scrolls produce emulated mousewheel events, and the scroll distance can be controlled with mousewheel.default.delta_multiplier_y.