commit 258ed8d55e4f8b4d99fcde72c3569b9450198092
author David Bokan <bokan@chromium.org> Wed Feb 20 17:20:28 2019
committer Commit Bot <commit-bot@chromium.org> Wed Feb 20 17:20:28 2019
tree dbffe94a2a8400f942a1bf472c3d65c6aa9cd685
parent 5c80a557974d651651a849e80bd442bbd12ae394

Synthetic input waits on compositor display

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.

Bug: 902446
Change-Id: Ib2dddee08400dfa1137c674c47c0d7106961162f
Reviewed-on: https://chromium-review.googlesource.com/c/1390329
Reviewed-by: Saman Sami <samans@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#633753}