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
(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.
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 =)
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.
Created attachment 333468 [details] Patch
Comment on attachment 333468 [details] Patch hmm, it would be interesting to know why GTK+ has 1000 there if we are going to diverge.
*** Bug 182669 has been marked as a duplicate of this bug. ***
Thanks for the patch. Works on my end on 2.19.90.
Comment on attachment 333468 [details] Patch I have other users complaining about this, so if it fixes the regression, let's land it.
(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.
^ Christian, you might be the best person to answer the question above. IIRC you wrote the original code that we copied from GTK+ (right?)
Comment on attachment 333468 [details] Patch Clearing flags on attachment: 333468 Committed r228368: <https://trac.webkit.org/changeset/228368>
All reviewed patches have been landed. Closing bug.
(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().