Created attachment 416361 [details] Test case Safari Technology Preview 117, on macOS 10.15.7 When scrolling inside a scroll container, after reaching the end, the scroll does not propagate to the parent scroll container (whether it is another element or the page) as long as the overscroll is ongoing. The current scroll has to be perfectly still for scroll-chaining to happen. See the attachment for a test case, also available here: https://output.jsbin.com/begomocugi Steps to reproduce: 1. scroll down to the end of the outer scroll (to reach the inner scroll) 2. scroll down inside the inner scroll, then up until reaching the top edge 3. scroll up again BEFORE the end of the overscroll Expected behaviour: the scroll should propagate to the outer scroll container as soon as a new "up" scroll happens, and the outer scroll container should scroll up as a consequence. Result: the inner scroll container get scrolled again, persisting in its overscroll. You have to wait for the overscroll to end completely to be able to scroll out of it. Scroll-chaining is thus made pretty unusable, as you have to wait for the overscroll to end in order to escape the current scroll context. This didn't happen in previous macOS Safari version (at least before STP 116, which I didn't test). To be noted: this problem has been present on iOS for a while. Not sure if I should create another bug for this? This bug might be related to this other one, on nested scrolling: https://bugs.webkit.org/show_bug.cgi?id=219923 Maybe it can even be considered as the same? As this bug (scroll-chaining) is present on iOS but not the other (nested scrolling) one I considered them to be different. As mentioned in the other bug, this might be a regression due to the recent changes on scrolling.
There's a 100ms timeout to clear latching which I think is a bit too long.
When is that timeout added exactly? It feels like there is a timeout preventing scroll chaining *after* the end of the overscroll. This doesn't seem useful, as it should be possible to scroll out of the inner scroll way before that, *during* the overscroll. If the user is overscrolling and scrolls again in the same direction, scroll chaining should take place right away. This is how it behaved before STP 117, and how it behaves in similar situations accross macOS and iOS native interfaces. Now maybe there can be a short timeout between the start of the overscroll and the possibility to trigger scroll chaining with a new scroll gesture, but I don't think this is when the timeout is used at the moment?
<rdar://problem/72595521>
Part of this is about ScrollController's behavior of ignoring momentum scrolls (m_ignoreMomentumScrolls) when we're done rubberbanding, but we continue to claim to handle the wheel events, which postpones releasing the latch.
Created attachment 418095 [details] Patch
https://trac.webkit.org/changeset/271730/webkit
I filed bug 236348 to followup on https://twitter.com/mtomweb/status/1491162786369777665