Bug 249912 – REGRESSION(256929@main): [GLib] Extremely poor keyboard scrolling performance on various websites, view scrolls in wrong direction

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Michael Catanzaro]

WebKitGTK 2.39.3 suffers from extremely poor keyboard scrolling performance on various websites. Whenever this happens, the scrolling lags for a bit, then the page content disorientingly jumps too far after it recovers. E.g. say I'm holding the down arrow key for four seconds, and the page scrolls down slowly at first, then when WebKit seems to "recover" from the lag it will instantly scroll down too far. Then I have to use the up arrow key to scroll back up, and hope I don't overshoot when the page content jumps again.

I haven't checked yet to be certain, but I suspect it's probably a regression from 256929@main.

Test page: https://thepointsguy.com/news/southwest-airlines-christmas-meltdown/

[Michael Catanzaro]

I have a guess at what might be happening here. WebKit scrolling performance has always been poor, with the web view frequently stalling during scroll. With 2.39.3, I think WebKit now continues "internally" scrolling during those periods of stall where it appears to the user that no scrolling is happening. So if I'm holding down an arrow key, WebKit will keep scrolling secretly, and when the stall ends it will overshoot big time. Then I have to manually scroll back to where I want to be using the mouse, since if I use the keyboard the same thing will happen again.

We might need to revert 256929@main.

[Michael Catanzaro]

Created attachment 464895 [details]
Demonstration screencast

Here's a video demonstrating the bug. During this video, I press and hold the down arrow on my keyboard, so the view should only ever scroll down, never up. We see the view hang at 1 second and scroll back to the top of the page at 5 seconds, even though it should only ever go down.

Here I'm compiling WebKit in the background, so the effect in this video is exaggerated due to the lag. Normally the effect is less severe than this, but it still happens to a lesser extent when my computer is under no strain.

[Michael Catanzaro]

Created attachment 464896 [details]
Better demonstration screencast, showing view scroll up while I hold the down button

[Michael Catanzaro]

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

[Michael Catanzaro]

Another good test page: https://www.cnn.com/2023/03/01/politics/merrick-garland-senate-judiciary-committee-testimony/index.html

[Alice Mikhaylenko]

So the weird thing is. We already had animations. Really fast and barely noticeable ones for up/down, but they were there - and much more noticeable for page up/down.

Now I heavily suspect those are still running along with the new ones, and the new animations are trying to interpolate _that_. And that's why it's so slow and has such a strange curve.

Meanwhile page up/down are nice and snappy as they are using the old animations.

[Carlos Garcia Campos]

It was animated before, but it didn't use async scrolling. I'll heck if we are doing both now...

[Carlos Garcia Campos]

(In reply to Alexander Mikhaylenko from comment #6)
> Meanwhile page up/down are nice and snappy as they are using the old
> animations.

Oh, this is a regression introduced in 259146@main

[Carlos Garcia Campos]

(In reply to Carlos Garcia Campos from comment #8)
> (In reply to Alexander Mikhaylenko from comment #6)
> > Meanwhile page up/down are nice and snappy as they are using the old
> > animations.
> 
> Oh, this is a regression introduced in 259146@main

See https://github.com/WebKit/WebKit/pull/11171

[Carlos Garcia Campos]

I can't reproduce this, does it happen with any website? Maybe this improved too after 261124@main?

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #10)
> I can't reproduce this, does it happen with any website?

Some websites are significantly worse than others, e.g. cnn.com is so bad that the view often appears to scroll in the opposite direction.

It's also worse under heavy CPU load, so compile WebKit at the same time you're trying to test it.

> Maybe this improved too after 261124@main?

I really hope so, but I have not tested yet.

[Michael Catanzaro]

Hm, this bug is back in 2.41.1 (because I only disable the keyboard scroll animator on the 2.40 branch, not on main) but it feels less severe than it did originally, so maybe this is OK.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #12)
> Hm, this bug is back in 2.41.1 (because I only disable the keyboard scroll
> animator on the 2.40 branch, not on main) but it feels less severe than it
> did originally, so maybe this is OK.

I don't think it's OK. It's especially severe when reading articles on cnn.com. When pressing the down arrow key on my keyboard, WebKit sometimes jumps from the top of the article all the way to the bottom of the article. I think the scroll animator is assuming that the view is scrolling with perfect performance, but users expect the scroll to be relative to what is actually displayed. If it takes a while for WebKit to begin scrolling down, that time with the key pressed should surely not be considered to mean "scroll really really far."

[EWS]

Committed 266908@main (f452a9733349): <https://commits.webkit.org/266908@main>

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