This is very specific; it works with touch or with async scrolling. See the patch, but I'm very much not sure that's correct as it's a later regression, from the 2.32.0 cycle
Created attachment 425147 [details] Patch
Drive-by comments; It does seem odd that we would stop the animation but not clear the scroll history - I'm reasonably sure this worked as expected when I originally checked in momentum scrolling, I'd be concerned that this might cause some unexpected behaviour (though obviously there currently is unexpected behaviour, so that's a bit of a moot point). If all of these things work with async and non-async scrolling, with GTK and WPE, I think this should be fine: - Touchscreen or touchpad scrolling without triggering a kinetic scroll animation - Touchscreen or touchpad scrolling and triggering a kinetic scroll animation - Increasing the velocity of a kinetic scroll animation with touchscreen or touchpad scrolling (momentum scrolling) - Stopping a kinetic scroll animation with touchscreen or touchpad scrolling - Smooth scrolling with a mouse-wheel and keyboard - Mouse-wheel or keyboard scrolling interrupting animated scrolling It's a lot to test... We briefly chatted on IRC, to reiterate what we discussed there, I think it'd be good to get API tests written for both the animation classes and the event-handling so that we can establish expected sequences and behaviours. Given this is currently completely untested, I don't think that should hold up this particular patch, but it'd establish a good precedent to at least add a test that would catch this particular failure (unexpected clearing of scroll history when calling scroll-to api).
Well, this function is called every time you scroll, resulting in the scroll history always being empty when you trigger kinetic scrolling. Maybe what changed between when you were reworking kinetic scrolling and now is it was only used in some special cases that do warrant clearing the history, and is more widely used now. Thanks for the list, I was gonna type that there is indeed a regression after going through the list: - Mouse-wheel or keyboard scrolling interrupting animated scrolling But seems it's in trunk as well. :(
(In reply to Alexander Mikhaylenko from comment #3) > - Mouse-wheel or keyboard scrolling interrupting animated scrolling Can you report a separate bug for this please?
Committed r277539 (237767@main): <https://commits.webkit.org/237767@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 425147 [details].
(In reply to Michael Catanzaro from comment #4) > Can you report a separate bug for this please? https://bugs.webkit.org/show_bug.cgi?id=225844