Bug 219923 - REGRESSION (Async overflow scroll): Scroll stutters/blocked with nested scrolling
Summary: REGRESSION (Async overflow scroll): Scroll stutters/blocked with nested scrol...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Scrolling (show other bugs)
Version: Safari Technology Preview
Hardware: Mac (Intel) macOS 10.15
: P2 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-12-15 15:04 PST by Bruno Stasse
Modified: 2021-01-21 10:46 PST (History)
15 users (show)

See Also:


Attachments
Test case (996 bytes, text/html)
2020-12-15 15:04 PST, Bruno Stasse
no flags Details
Patch (16.15 KB, patch)
2021-01-20 15:33 PST, Simon Fraser (smfr)
sam: review+
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (16.80 KB, patch)
2021-01-20 20:42 PST, Simon Fraser (smfr)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bruno Stasse 2020-12-15 15:04:39 PST
Created attachment 416298 [details]
Test case

Safari Technology Preview 117, on macOS 10.15.7

With one scroll container containing another scroll container. The outer one is set to overflow-x: auto, and the inner one to overflow-y: auto.

See the attachment for a simple test case, also available here: https://output.jsbin.com/cuvehilufi

Steps to reproduce:
1. scroll vertically (inner) with a trackpad
2. scroll horizontally (outer) with a trackpad BEFORE the end of the momentum, OR BEFORE the end of overscroll if you reach the end of the scroll container

Expected behaviour: the outer container should scroll horizontally right away.
Result: the scroll stutters and gets blocked.

This happens in all directions, with the inner or the outer scroll. It didn't happen in the previous version of Safari (at least not until 116 which I didn't test).
This makes nested scrolling pretty unusable, because you have to wait for the end of the momentum and overscroll to scroll in another direction.

I guess this is a regression due to the recent changes on scrolling.
Comment 1 Simon Fraser (smfr) 2020-12-16 10:31:32 PST
I can reproduce.
Comment 2 Radar WebKit Bug Importer 2020-12-16 10:31:43 PST
<rdar://problem/72390196>
Comment 3 Simon Fraser (smfr) 2020-12-22 14:53:41 PST
I think this is because we re-compute latching for a "MayBegin" event (fingers down, stationary, on the trackpad) but not a "Begin" event (fingers down with movement).
Comment 4 Simon Fraser (smfr) 2020-12-22 16:39:32 PST
Actually I think this is mainly triggered by:

            overflow-x: hidden;
            overflow-y: auto;

when there is x-overflow.
Comment 5 Simon Fraser (smfr) 2021-01-07 15:48:53 PST
I fixed at least some of the issues here in r271090.
Comment 6 Simon Fraser (smfr) 2021-01-07 15:49:58 PST
I can still reproduce some issues though.
Comment 7 Simon Fraser (smfr) 2021-01-07 16:44:17 PST
There are some issues here about what happens when we send a wheel event with x-axis deltas to a latched y-axis scroller, but the underlying cause of stuttering is that a latched scroller receives a stream of events for the cross axis and doesn't handle them, which causes the latch in ScrollingTreeLatchingController to time out, so at point we hit-test again and find a different scroller and start sending events to it.
Comment 8 Simon Fraser (smfr) 2021-01-20 15:33:39 PST
Created attachment 418001 [details]
Patch
Comment 9 Simon Fraser (smfr) 2021-01-20 20:42:08 PST
Created attachment 418020 [details]
Patch
Comment 10 EWS 2021-01-21 10:46:12 PST
Committed r271701: <https://trac.webkit.org/changeset/271701>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 418020 [details].