commit | f92eaf26c9c54590bdaa2f4e2cc0aee8d031fde0 | [log] [tgz] |
---|---|---|
author | David Bokan <bokan@chromium.org> | Fri Mar 01 01:54:51 2019 |
committer | Commit Bot <commit-bot@chromium.org> | Fri Mar 01 01:54:51 2019 |
tree | c7cad46650acd77503a0862ec7b82f031fd99d70 | |
parent | c9a56a176ba1dfa89bf1d8b22933bc253eab7195 [diff] |
[Reland] Synthetic input waits on compositor display Reland #2 Note: { Previously (re-)landed: https://crrev.com/b37e23cbd52ba447ab89c6d18f4ea0ecdc3fa5c0 Reverted: https://crrev.com/a9aa35a2fb904074cddb4e2d889217a899177721 More leaky tests. Though we now resolve gesture callbacks at the end of the test, the callback may come in after the test. This re-land fixes the leaky tests by finishing the test only once the gesture is completed. Previously landed CL uploaded as PS1, fixed in PS2. NOTE TO SHERIFF: If this is causing issues on the leak bots, please ping me or disble the test rather than reverting, if possible. } This CL makes synthetic input - the kind used in web tests and telemetry (e.g. gpuBenchmarking.scrollBy) - wait until a CompositorFrame has been submitted by the renderer and displayed by the display compositor before resolving the completion callback. This means client code that wants to wait until any observable side-effects of this input is visible to further input need only wait on the gesture's completion callback. To give a motivating example: suppose we wish to write a test that scrolls an out-of-process iframe into view and clicks on a button in the frame. The code might look something like this: gpuBenchmarking.smoothScroll(1000, () => { gpuBenchmarking.tap(0, 0); }); This code contains a race today. The callback for smoothScroll is invoked as soon as the ScrollEnd is received in the renderer. However, until a new compositor frame is submitted from the renderer, the tap may occur against stale hit testing geometry. This is a major source of flakiness in our tests. This CL fixes the problem by forcing the renderer to perform a full redraw at the end of each gesture. The redraw produces a compositor frame and we invoke the callback once the compositor frame is displayed. We do this by reusing the RequestPresentation mechanism in RenderWidget. RequestPresentation required two modifications to work in web tests which use a single thread proxy with no scheduler: - LayerTreeHost::Composite needs to check the forced redraw flag to determine whether we need to raster, otherwise it won't produce a frame - RequestPresentation must request a main frame since there's no scheduler to perform the commit, which is what SetNeedsForcedRedraw requests. The timing change exposed an issue in the overlay-play-button-tap-to-hide.html test so this CL also cleans that test up to listen to the animation changes in media controls properly. Finally, it's possible we may get input in a RenderWidget that's not currently displayed. e.g. A click event sent via ChromeDriver causes a TouchStart followed by a TouchEnd. The TouchStart causes a window.open which opens and focuses a new tab. The TouchEnd then happens on the background tab. In this case, we should resolve the callback rather than waiting on a CompositorFrame that'll never come. See ChromeDriver test testNetworkConnectionTypeIsAppliedToAllTabs for an example of this. TBR=dtapuska@chromium.org,nzolghadr@chromium.org,samans@chromium.org,peter@chromium.org Bug: 902446 Change-Id: I0f818168b3f36070f72369a072e7f5eac64eb77c Reviewed-on: https://chromium-review.googlesource.com/c/1496244 Commit-Queue: David Bokan <bokan@chromium.org> Reviewed-by: David Bokan <bokan@chromium.org> Cr-Commit-Position: refs/heads/master@{#636654}
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure .