Bug 178519 – [GTK] Scrolling sometimes jumps around

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

[Gustavo Noronha (kov)]

I noticed after updating to a more recent WebKitGTK+ that sometimes when I'm panning through a page using two-finger scrolling it will jump to the end of the page (or to the top if panning towards the top). I haven't investigated deeply yet, but I have a gut feeling it may be related to Bug 155750. I think the kinetic scrolling might be getting triggered with bad values. I added this debugging printf to the top of ScrollAnimationKinetic::start:

fprintf(stderr, "%s: %.2fx%.2f\n", __func__, velocity.x(), velocity.y());

It prints this when the jump happens:

start: -136363,47x534090,25

[Michael Catanzaro]

(In reply to Gustavo Noronha (kov) from comment #0)
> I haven't investigated
> deeply yet, but I have a gut feeling it may be related to Bug 155750.

Almost surely.

[Gustavo Noronha (kov)]

Yes, I think computeVelocity() is going nuts and calculating something that causes a very speedy kinetic scrolling animation to be started when a non-momentum scroll ends.

computeVelocity: -28410,07x308959,53 accumDelta.y(): -27,19 (last - first).value(): 0,09

The first values are what computeVelocity is about to return, with the components of the formula it uses following it. Remember that accumDelta.y() is multiplied by -1000 before it is divided by last - first.

I forgot to say I'm on Wayland, unsure if it is relevant, but hey.

Adding Adrien to CC as he's probably the one who understands what's intended for computeVelocity() better =)

[Michael Catanzaro]

This code was actually written by Adrien Plazas, not Adrian Perez. Adrien was just doing an internship with Igalia, so I doubt we can CC him directly on this bug. But he as active in the gamepad thread on the webkit-gtk mailing list, so it shouldn't be hard to get his attention.

[Gustavo Noronha (kov)]

Created attachment 333468 [details]
Patch

[Carlos Garcia Campos]

Comment on attachment 333468 [details]
Patch

hmm, it would be interesting to know why GTK+ has 1000 there if we are going to diverge.

[Michael Catanzaro]

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

[ManDay]

Thanks for the patch. Works on my end on 2.19.90.

[Michael Catanzaro]

Comment on attachment 333468 [details]
Patch

I have other users complaining about this, so if it fixes the regression, let's land it.

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #5)
> Comment on attachment 333468 [details]
> Patch
> 
> hmm, it would be interesting to know why GTK+ has 1000 there if we are going
> to diverge.

I'd be interested to know this too.

[Michael Catanzaro]

^ Christian, you might be the best person to answer the question above. IIRC you wrote the original code that we copied from GTK+ (right?)

[WebKit Commit Bot]

Comment on attachment 333468 [details]
Patch

Clearing flags on attachment: 333468

Committed r228368: <https://trac.webkit.org/changeset/228368>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Christian Hergert]

(In reply to Michael Catanzaro from comment #10)
> ^ Christian, you might be the best person to answer the question above. IIRC
> you wrote the original code that we copied from GTK+ (right?)

I only wrote the patch to make it settle without jitter.

But looking quickly over that code, the 1000 is probably related to the adjustment scaling in gtkscrolledwindow.c get_scroll_unit().