Bug 255193 - Consider not stopping scroll inertia animations when setting scrollTop, or, recalculate the animation and resume it.
Summary: Consider not stopping scroll inertia animations when setting scrollTop, or, r...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Scrolling (show other bugs)
Version: Other
Hardware: iPhone / iPad All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2023-04-08 13:02 PDT by nick
Modified: 2024-05-03 05:35 PDT (History)
6 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description nick 2023-04-08 13:02:14 PDT 
At the moment, using Webkit (WkWebView) on iOS, when the user sets the `scrollTop` property of a scrollable div, WebKit currently clears all running animations on that ScrollView (Which includes rubber-band / touch inertia animations).

This makes it impossible to create a smoothly scrolling div, that adjusts the scroll position while the user swipes to scroll (The user will snap to the position with all momentum halting abruptly).

It is also worth noting that all stock iOS & macOS native controls allow you to keep the momentum going when adjusting the scroll position.

Chromium on Android preserves the momentum and continues the animation as if it was started from the new scroll position.

It would make sense to preserve this when the user wants inertia / rubber-banding.

The relevant code that is currently stopping the animation is:

https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.cpp#L306

Which on iOS, is calling the following API `_stopScrollingAndZoomingAnimations` on the UIScrollView:

https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm#L337
Comment 1 Radar WebKit Bug Importer 2023-04-10 10:53:48 PDT 
<rdar://problem/107840440>
Comment 2 nick 2023-05-26 10:28:50 PDT 
Is this change something worth investigating? I would contribute the time to fix this if so.
Comment 3 Simon Fraser (smfr) 2023-05-26 13:57:16 PDT 
Yes, I think it is to match other browsers.
Comment 4 Bruno Stasse 2024-05-03 05:35:38 PDT 
I have several use cases that this behavior is preventing, one of them being a lightweight implementation of virtual scrolling. A change would be very much welcome.