GitLab

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}