Don't queue scroll update for first wheel scroll update in sequence
crrev.com/c/1774911 changed how the first scroll update is detected. That information is consumed in order to determine whether or not a scroll update event should get queued and dispatched on the next begin frame, or if it should be dispatched immediately. The refactoring had a logic bug because it was trying to detect GSB within the block of has_ongoing_compositor_scroll_or_pinch_ and thus the flag was never reset. This wasn't caught by the unittest for this behavior since the flag was initialized to false in the constructor. I'm adding another scroll begin update sequence to the unittest so that we have coverage on the state transition. Bug: 1002045 Change-Id: I781d782de794ccb0639d972325a4579e1c61abe2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1816360 Commit-Queue: Daniel Libby <dlibby@microsoft.com> Reviewed-by:David Bokan <bokan@chromium.org> Cr-Commit-Position: refs/heads/master@{#698673}
Showing
Please register or sign in to comment