Bug 168300 – [GTK] Slow scroll adjustment when using a mouse wheel

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Cédric Bellegarde]

Created attachment 301484 [details]
Epihany vs Firefox

I'm using Epiphany as a test but it's the same with all web browser using WebkitGtk2.

When using a touchpad (with and without smooth scrolling), scrolling is ok, same behaviour as Firefox.

When using a mouse wheel, scrolling increments are too short and scrolling a whole page is killing my finger!

Look at attachement, one mouse wheel on Firefox and one mouse wheel in epiphany.

Don't know how Gecko deal with that but WebKitGTK should not use same adjustment for touchpad and mouse wheel.

[Cédric Bellegarde]

Manage to bypass this issue here:
https://github.com/gnumdk/eolie/commit/4c46ff1b135d89d69b8a1b4741d99e694d26a457

But webkitgtk should be able to manage this by default.

[Michael Catanzaro]

*** Bug 177183 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

We received negative feedback about this from Linux Saloon: https://www.youtube.com/watch?v=3xJiQTYwksM. Our mouse wheel scrolling is several times slower than Firefox, and reportedly also Chrome. We should probably adjust this to more closely match other browsers, to avoid complaints.

[Michael Catanzaro]

Hey Chris, what do you think about speeding up mouse wheel scrolling to match what Firefox and Chrome do?

[Chris Lord]

(In reply to Michael Catanzaro from comment #4)
> Hey Chris, what do you think about speeding up mouse wheel scrolling to
> match what Firefox and Chrome do?

I think we should match what gtk does in a scrolled window (which I think is what we currently try to do?) - If that's too slow, I've no objection to speeding it up to what people expect from other browsers, but I'd suggest that it needs changing in Gtk as well.

If we're slower than a GtkScrolledWindow, that would be a bug that needs fixing.

[Michael Catanzaro]

I'm not sure how to measure this accurately, but I'd say we seem to approximately match GtkScrolledWindow currently.

[Berend De Schouwer]

I've got a video of gnome-text-editor versus epiphany, scrolling a text file, with the files zoomed similarly (40 lines visible), scrolling as fast as I can.

text editor is at least twice as fast as epiphany, and hits the bottom of the file (1000 lines) easy.

This isn't an exact test, I know.

[Berend De Schouwer]

Created attachment 459100 [details]
video of scrolling epiphany vs gnome-text-editor

[Michael Catanzaro]

So we've been continuing to receive complaints about the scroll adjustment. Let's forget about matching GtkScrolledWindow and match Firefox instead. Matching GTK is generally good to do, but often we decide to match other web browsers instead and that makes most sense here IMO.

[Carlos Garcia Campos]

I don't think we are matching gtk, but Safari. We use a fixed value of 40 pixels per line step, defined in WebCore::Scrollbar::pixelsPerLineStep() for all platforms. I think gtk has a different value depending on the document size:

scroll_step = pow (page_size, 2.0 / 3.0);

[Fabian Bornschein]

I'm not a developer so I have not really an idea if even one of them is possible so please don't cringe to hard on this :)

I think probably the best option would be to expose it to the downstream developer to configure it themself. With a hint that 120 is a good value, as it's used by chromium¹, should feel familiar and something like 60 is a nice value for list views and so on.

Another, more fixed, option would be to expose something like a context switch. Where the developer could set if they want to have a browser like- or a desktop app like experience. and the value changes to 120 for browser and 60 for desktop app.


¹ https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/resources/gesture-util.js;l=403;bpv=1;bpt=0


----
What I wonder, this is the general setting and so also for macOS/iOS families? Why are they not hit by that. I mean safari scrolling is not like chrome, but it doesn't feel like they use the same value as epiphany.

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #10)
> I think gtk has a different value depending on the document
> size:
> 
> scroll_step = pow (page_size, 2.0 / 3.0);

Well we can probably forget about matching GTK scroll speed then. That simplifies this discussion.

(In reply to Fabian Bornschein from comment #11)
> I think probably the best option would be to expose it to the downstream
> developer to configure it themself.

Well it's certainly possible, but now you're looking at adding new API, and then hoping that the application you care about rebuilds to use the new API. So it's a more involved process.

[Michael Catanzaro]

(In reply to Fabian Bornschein from comment #11)
> I think probably the best option would be to expose it to the downstream
> developer to configure it themself. With a hint that 120 is a good value, as
> it's used by chromium¹, should feel familiar and something like 60 is a nice
> value for list views and so on.

So thanks for linking to this code. One easy solution is to simply copy what Chrome does: use 40 for Apple (matching what we already have) and 120 for everything else. (Could also use 63 for Android, except Android support is only maintained downstream currently.) That way we can do it now without waiting until September to add new API, and revert it whenever if we change our minds. Adding API makes everything much more complicated.

[Michael Catanzaro]

Actually the file you linked to is just a JS test. :P But I bet it matches the real code, and it seems sensible....

[Michael Catanzaro]

Pull request: https://github.com/WebKit/WebKit/pull/11197

[Carlos Alberto Lopez Perez]

Chromium uses 120 both on Windows and Linux.

Refs:

- https://github.com/chromium/chromium/blob/ad90ee89ca306/ui/events/x/events_x_utils.cc#L36

- https://chromium.googlesource.com/chromium/src/+/e582cad2482263b0b3f0c04a6daa614b9c074014

[Carlos Garcia Campos]

Pull request: https://github.com/WebKit/WebKit/pull/11758

[EWS]

Committed 261961@main (645e981e523d): <https://commits.webkit.org/261961@main>

Reviewed commits have been landed. Closing PR #11758 and removing active labels.