Issue 760215  has been merged into this issue.

This is used to signal to tests that they are ready for sending input.

As a part of  issue 750755  there is a reworking of how hittestdata is provided to Viz. Once that is updated this signaler can be updated to reflect the internal state of the client, that it has provided hit test data. Which would mean that tests can then continue.

What do we replace SurfaceHitTestReadyNotifier with? Will there be an API added to Viz that lets content know if/when a given target can have input events routed to it?

We need to decide on an appropriate API for this. Hopefully one that breaks the dependency on the compositing logic.

I'll look further into the tests using this to see if they are awaiting some JS handler to be installed, in which case some other message could signal them being ready.

Though at the point where content provides hittestdata to Viz, we might similarly know that we are ready for processing.

I'll look further.

 Issue 774269  has been merged into this issue.

This apparently is already causing issues in the mus config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/13e9b1509501a00090df8599eb02fae4e8e96262

commit 13e9b1509501a00090df8599eb02fae4e8e96262
Author: Jonathan <jonross@chromium.org>
Date: Wed Oct 25 14:54:33 2017

Disabling flaking mus_browser_tests

WebView related tests are flaking. With AutoSize timing out, and
PDFExtensionTest using an unsupported util.

TBR=sky@chromium.org

Bug: 755328,  763452 
Change-Id: I0c9388e880b8d0923e7df05cbfac0d7a7ba9e186
Reviewed-on: https://chromium-review.googlesource.com/737578
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511457}
[modify] https://crrev.com/13e9b1509501a00090df8599eb02fae4e8e96262/testing/buildbot/filters/mojo.fyi.mus.browser_tests.filter
[modify] https://crrev.com/13e9b1509501a00090df8599eb02fae4e8e96262/testing/buildbot/filters/mus.browser_tests.filter

Replacing WaitForChildFrameSurfaceReady is currently blocked.

The use-case of this method is to wait until child frames are setup in such a way that they can process input.

In pre viz input handling this would ideally be ran off of FrameHostMsg_HittestData. However RenderWidgetHostInputEventRouter::RouteMouseEvent is currently doing quad-based hit testing on Surfaces. So having received the hit test data is not sufficient.

Similarly the MainThreadFrameObserver is not sufficient, as ViewMsg_WaitForNextFrameForTests does not guarantee that each compositor has submitted a frame.

There is a design for a test observer that tracks surface activation, along with compositor frame submission. However this is inherently racey. As there is no method to force a compositor frame to be generated. So the observer would be racing to get setup before rendering began.

Migrating from Internals>Viz to Internals>Services>Viz.

WebViewGuest is also crashing at launch right now for --enable-viz.

So that needs to be fixed before the other replacements can be made.

Once FrameToken piping is ready we can replace some WaitForChildFrameSurfaceReady with MainThreadFrameObserver as parts of the test only care about the next frame occurring.

Once the hit test rework is done, then the rest of the WaitForChildFrameSurfaceReady can be replaced with an observer waiting to see the hit test data. As that is sufficient for tests wanting to block until input is ready.

After this is unblocked the following steps are needed to resolve:
  -  Replace some WaitForChildFrameSurfaceReady with MainThreadFrameObserver
  -  Update SurfaceHitTestReadyNotifier with observing the new hit test data path.
  -  Update WaitForChildFrameSurfaceReady to use new hit test observer
  -  Replace WaitForGuestSurfaceReady in the same manner
 

Any thoughts on whether it would be feasible to move the 'wait for hit test data' step into the navigation helper functions? (i.e. NavigateToURL, NavigateFrameToURL, and related.)

It would be nice because people sometimes forget to put the waiting step in and we get flaky tests. I just had a CL reverted twice because it caused unrelated tests to flake that were missing WaitForChildFrameSurfaceReady().

A catch might be that NavigateToURL would have to figure out how many OOPIF subframes are loading in order to wait for their compositor frames.

In theory surface sync could automagically make this all better. If the top most frame has received a DidReceiveCompositorFrameAck (and we turn off deadlines for tests), then the whole subtree will have CompositorFrames.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9e66f6a2648e6dd60e292806c011a45d179b76d5

commit 9e66f6a2648e6dd60e292806c011a45d179b76d5
Author: Jonathan <jonross@chromium.org>
Date: Wed Nov 15 20:08:53 2017

Have Mus Embedded Frames Tell Child Frame of new FrameSinkId

In --mus the embedding of child guest frames happens in the viz service.

This introduces a new frame message which allows RenderFrameProxy to notify the
CrossProcessFrameConnector of a new FrameSinkId. This is then set on the
associated RenderWidgetHostViewChildFrame.

This will unblock being able to unittest guest views.

TBR=sky@chromium.org
TEST= manual testing of chrome --mus with a guest view.

Bug:  763452 , 755328
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: Ie5ebbcf82764d01f7205b1a567506981a8b4b609
Reviewed-on: https://chromium-review.googlesource.com/748772
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516801}
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/browser/frame_host/cross_process_frame_connector.cc
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/browser/frame_host/cross_process_frame_connector.h
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/browser/mus_util.h
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/browser/renderer_host/input/touch_selection_controller_client_aura_browsertest.cc
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/browser/renderer_host/render_widget_host_view_child_frame.cc
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/browser/renderer_host/render_widget_host_view_child_frame.h
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/browser/renderer_host/render_widget_host_view_child_frame_browsertest.cc
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/common/frame_messages.h
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/renderer/render_frame_proxy.cc
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/test/content_browser_test_utils_internal.cc
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/content/test/content_browser_test_utils_internal.h
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/testing/buildbot/filters/mojo.fyi.mus.browser_tests.filter
[modify] https://crrev.com/9e66f6a2648e6dd60e292806c011a45d179b76d5/testing/buildbot/filters/mus.browser_tests.filter

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/068adbcb6e8317025291723f02f93fea59706a88

commit 068adbcb6e8317025291723f02f93fea59706a88
Author: jonross <jonross@chromium.org>
Date: Wed May 30 18:04:47 2018

Converting WaitForChildFrameSurfaceReady to RenderFrameSubmissionObserver

There are a few sites in site_pre_process_browsertest which use WaitForChildFrameSurfaceReady to simply wait a frame. This updates those calls to use RenderFrameSubmissionObserver.

There are a few others, however the rest of those tests also need the new hit test api, so I'll convert them later.

SitePerProcessBrowserTest.CompositorViewportPixelSizeTest, SitePerProcessBrowserTest.NavigateCrashedSubframeToSameSite

Bug:  763452 
Change-Id: Ic651a67896b6174559bb50299b267237b0cd7b9b
Reviewed-on: https://chromium-review.googlesource.com/1077817
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/master@{#562912}
[modify] https://crrev.com/068adbcb6e8317025291723f02f93fea59706a88/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/068adbcb6e8317025291723f02f93fea59706a88/content/public/test/browser_test_utils.cc
[modify] https://crrev.com/068adbcb6e8317025291723f02f93fea59706a88/content/public/test/browser_test_utils.h
[modify] https://crrev.com/068adbcb6e8317025291723f02f93fea59706a88/testing/buildbot/filters/viz.content_browsertests.filter

browser_test_utils no longer requires Viz service.