Bug 168300 - [GTK] Slow scroll adjustment when using a mouse wheel
Summary: [GTK] Slow scroll adjustment when using a mouse wheel
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Carlos Garcia Campos
URL:
Keywords:
: 177183 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-02-14 03:53 PST by Cédric Bellegarde
Modified: 2023-03-22 06:22 PDT (History)
9 users (show)

See Also:


Attachments
Epihany vs Firefox (728.38 KB, video/webm)
2017-02-14 03:53 PST, Cédric Bellegarde
no flags Details
video of scrolling epiphany vs gnome-text-editor (2.26 MB, video/webm)
2022-05-10 01:20 PDT, Berend De Schouwer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cédric Bellegarde 2017-02-14 03:53:29 PST
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.
Comment 1 Cédric Bellegarde 2017-02-14 04:11:20 PST
Manage to bypass this issue here:
https://github.com/gnumdk/eolie/commit/4c46ff1b135d89d69b8a1b4741d99e694d26a457

But webkitgtk should be able to manage this by default.
Comment 2 Michael Catanzaro 2017-09-26 08:09:01 PDT
*** Bug 177183 has been marked as a duplicate of this bug. ***
Comment 3 Michael Catanzaro 2022-04-11 07:16:34 PDT
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.
Comment 4 Michael Catanzaro 2022-05-05 20:19:31 PDT
Hey Chris, what do you think about speeding up mouse wheel scrolling to match what Firefox and Chrome do?
Comment 5 Chris Lord 2022-05-09 07:20:50 PDT
(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.
Comment 6 Michael Catanzaro 2022-05-09 07:30:00 PDT
I'm not sure how to measure this accurately, but I'd say we seem to approximately match GtkScrolledWindow currently.
Comment 7 Berend De Schouwer 2022-05-10 01:19:03 PDT
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.
Comment 8 Berend De Schouwer 2022-05-10 01:20:09 PDT
Created attachment 459100 [details]
video of scrolling epiphany vs gnome-text-editor
Comment 9 Michael Catanzaro 2023-03-06 12:25:06 PST
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.
Comment 10 Carlos Garcia Campos 2023-03-07 01:36:24 PST
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);
Comment 11 Fabian Bornschein 2023-03-07 02:54:14 PST
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.
Comment 12 Michael Catanzaro 2023-03-07 14:07:17 PST
(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.
Comment 13 Michael Catanzaro 2023-03-07 14:22:42 PST
(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.
Comment 14 Michael Catanzaro 2023-03-07 14:23:50 PST
Actually the file you linked to is just a JS test. :P But I bet it matches the real code, and it seems sensible....
Comment 15 Michael Catanzaro 2023-03-07 15:38:25 PST
Pull request: https://github.com/WebKit/WebKit/pull/11197
Comment 17 Carlos Garcia Campos 2023-03-21 07:06:59 PDT
Pull request: https://github.com/WebKit/WebKit/pull/11758
Comment 18 EWS 2023-03-22 06:21:56 PDT
Committed 261961@main (645e981e523d): <https://commits.webkit.org/261961@main>

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