Created attachment 356442 [details] Exhibits scroll boundary breaking behavior between inner scrollable element and ancestor snapport Here's another one for you wenson_hsieh@apple.com. Wish I had the time to offer an actual reduced test case, and this may have some crossover with fred.wang@free.fr work in https://bugs.webkit.org/show_bug.cgi?id=176454, but for now, I offer what I think is a fairly straight forward ui, with attached video, that shows the bug... 1. Open attached test case and se trackpad and inertial scrolling in safari. 2. Scroll down while hovering mouse over the pink background text, don't scroll all the way to the bottom edge of itself. 3. Start another scroll interaction down to meet the bottom edge of the scroll container. 4. Once momentum has stopped the scroll interaction, try to scroll passed that bottom edge, attempting to scroll the ancestor scroller, which is a snapport, passed that boundary. 5. If you disable the `scroll-snape-type` property on the ancestor scroller, '.root-inner', you will see the scroll chaining bug disappear, allowing normal scroll chaining behavior passed that bottom edge boundary. Witnessed: Attempt you may, but you will never get the browser to chain up the scroll interaction to the ancestor scroller, which would bring in the white squares that sit just off the bottom edge of the screen. It will never scroll up into view and even some frames flicker, almost trying snap up in one frame before resolving back down off screen. Expected: Even with the ancestor scroller using snapping, the internal scrolling element should allow normal "overscroll" scroll chaining behavior passed its scroll boundaries. Video: http://cl.ly/b8151e101cd4 PS Safari doesn't currently support `overscroll-behavior`, so the use of those properties in the testcase are purely for testing across other vendors, though again, this may implications with webkits eventual support of the property.
For comparison, if you open that test case in the current chrome canary, but remove all uses of `overscroll-behavior`, you would see the expected behavior shown in this video http://cl.ly/e441a377de4f
Created attachment 359171 [details] scroll snapped outter scroller blocked by inner scroller at boundary I *think this test case narrows down the original real world ui test case I previously attached. 1. Scroll downwards with mouse over green area. This scrolls a scroll snapping outer container. 2. Watch as it snaps to the second/last page of it's content. 3. Scroll downwards with mouse over striped area. This scrolls an internal scroll container. 4. Let internal scroll resolve at bottom boundary, then scroll back up to the top boundary. 5. Try as you might to continue scrolling upwards from above the striped area, you will not be able to scroll back up to the first page of the outer scroll snapping container. fred.wang@free.fr I think this is the culprit of the tangential issue described in https://bugs.webkit.org/show_bug.cgi?id=191816
Here is a video of the steps/test for attachment 359171 [details] http://cl.ly/77a6a5f78112
Another way to see the strangeness between scroll chaining and scroll-snap is shown in this simple video of the more reduced test case that is attached. http://cl.ly/8044130b495b Here on initial load of the case, the first downward scroll gesture from a trackpad at a strength that scrolls the internal scroller passed its full scrollHeight will fully scroll that internal scroller and then extend out (chain) up to the ancestor scroller, but not initiate the snapping behavior that is on the ancestor scroller. The video shows that this can leave the ancestor scroller resolving at a position that isn't a snap position.
Created attachment 360172 [details] scroll snapped outter scroller blocked by inner scroller at boundary Replaces 359171, exhibits the same buggy behaviors, but now inner non-snapping scrollers are easier to see being inset further within the outer snapport.
Hey fred.wang@free.fr have you had a chance to look at this?
(In reply to jonjohnjohnson from comment #6) > Hey fred.wang@free.fr have you had a chance to look at this? Thanks for the detailed report and sorry I haven't had a chance to look into it again. I'm going to move to other tasks unrelated to scrolling for a while so I'm not sure when I'll go back to this. Now that bug 191816 has landed it would be interesting to know if that improves things here, but my guess would be that it is indeed independent.
The primary issue that seems related and possibly covers this would be https://bugs.webkit.org/show_bug.cgi?id=176454, the issue for implementing overscroll-behavior?
<rdar://problem/96320132>