Execute scrollIntoView scrolls in parallel
Blink currently handles scrolls generated by scrollIntoView by executing
the scrolls one after the other. To manage this, Blink would have a new
sequence abort the old sequence. This led to a limitation where smooth
scrollIntoViews could not be run on separate scrollers at the same time.
This patch changes this behavior so that Blink will run all the scrolls
generated by scrollIntoView in parallel.
This allows smooth scrollIntoViews to be run on separate scrollers
simultaneously and allows scrollIntoView scrolls to be ticked on the
compositor thread. It is also similar to what Firefox and Safari do.
Additional Notes:
active_smooth_scroll_into_view_type_ is introduced to
ScrollableArea so that we can preserve our filtering logic but enforce
it on a per-scroller basis, e.g. as tested by
ScrollIntoViewTest.SmoothUserScrollNotAbortedByProgrammaticScrolls.
The modification to scrollend-event-fired-for-scrollIntoView.html makes
sure that both the out_div and the target_div have finished scrolling
before verifying their scroll offsets.
scrollIntoView-smooth.html is modified because now that scrollIntoView
is ticked on the compositor thread, counting frames is not a reliable
way to signal the end of the scroll. Instead, we wait for the scrollend
event. The method of counting frames is not deleted so the test can
remain passing on browsers that don't have scrollend enabled as this is
a fairly old test.
Bug: 325081538
Change-Id: Ia004b5e94ade5c5dae836a0996143476157a132a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5560484
Reviewed-by: Robert Flack flackr@chromium.org
Commit-Queue: David Awogbemila awogbemila@chromium.org
Cr-Commit-Position: refs/heads/main@{#1315794}