Use gesture injection for remaining main thread scrollbar scrolls.
Use the InjectGestureScrollEvent API to additionally generate gesture events to scroll when dragging the thumb, tapping scrollbar parts or handling gestures forwarded from the browser process. Instead of invoking ScrollableArea::UserScroll or SetScrollOffsetSingleAxis, we'll instead generate the appropriate sequence of scroll gesture events to further unify how scrollbar scrolls are performed and allow us to gather latency metrics on them. This is done under the ScrollbarInjectsScrollGestures feature flag (currently off by default). For thumb moves, we don't know which direction the scroll will be when we get MouseDown on the thumb part, which can cause the correct node to not get added to the scroll chain. Because of this, we use the existing pattern of generating the GestureScrollBegin 'on demand' when we inject the first GestureScrollUpdate. This removes the need to inject GSB on MouseDown, since it works the same way for mouse-down on other parts as well. Additionally, if we inject scroll gestures targeted at a ScrollableArea, in ScrollManager we don't route those gestures to the scrollbar_handling_scroll_gesture_ but instead bypass and just use the event_target/scroll_gesture_handling_node_ which was set when the ScrollableArea was targeted. This allows for GSB/GSU sent from the browser process to continue to be handled by the scrollbar code (needed in order to reverse the scroll direction and make the scroll proportional to the scroller/scrollbar size) while the injected scroll updates (interleaved with those from the browser process) target the scrollable area and perform the actual scroll. One other note: currently, gestures targeting a scrollbar do not snap when the gesture is completed. Because the scrollbar is handling the updates (returns true from Scrollbar::GestureEvent) the logic to handle snapping is never executed. This change fixes this completely for scroll gestures on scrollbars, but has the side effect of scrollbar taps on track/buttons to not have a visual effect in the face of snapping. The code currently just immediately injects a GSE - this is processed before there is any visual indication of the scroll happening and thus to the user, it doesn't look like a scroll happened. This will be addressed in a follow up change to post a delayed task that will inject a gesture scroll end and clear the pressed part, etc. Bug: 954007 Change-Id: Ic8a641a3183d5613088a3392bb6bde8fe44e45e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1633112Reviewed-by:Timothy Dresser <tdresser@chromium.org> Reviewed-by:
David Bokan <bokan@chromium.org> Commit-Queue: Daniel Libby <dlibby@microsoft.com> Cr-Commit-Position: refs/heads/master@{#664801}
Showing
This diff is collapsed.
Please register or sign in to comment