Dmitry, Could you please take a look this issue? Thanks.

The tests hangs in content::WaitForChildFrameSurfaceReady in mus_browser_tests [1].

Cc'ing folks who might help here. Any ideas? Should we disable the test for mus (and how)?

[1] https://logs.chromium.org/v/?s=chromium%2Fbb%2Fchromium.chromiumos%2Flinux-chromeos-rel%2F5812%2F%2B%2Frecipes%2Fsteps%2Fmus_browser_tests%2F0%2Flogs%2FSitePerProcessDevToolsSanityTest.InputDispatchEventsToOOPIF%2F0

Jon/Fady, isn't this a known issue?   Issue 787945 ? Maybe you guys could put a DCHECK in WaitForChildFrameSurfaceReady that tells developers that it isn't supported yet under mus, links to a bug or suggestion on how to work around?

I would skip the test in testing/buildbot/filters/mus.browser_tests and probably mash.browser_tests too.

I haven't heard of issues with WaitForChildFrameSurfaceReady in mus before.

We got ride of the mus.browser_tests filter because they were all passing, which includes a large number of calls to that method.

It timing out implies that there is something wrong with that particular test. The VizDisplayCompositor issues for example involve the method crashing.

Ah, then it sounds like a real problem. My mistake.

Thanks everyone, but that didn't really help :)

What could be wrong with that specific test? It doesn't do anything [1]: NavigateToURLBlockUntilNavigationsComplete and then WaitForChildFrameSurfaceReady.

Unfortunately, I have no idea how to even start debugging this. I am totally fine to disable this test for mus_browser_tests just to make FYI bot green, if that's fine.

[1] https://cs.chromium.org/chromium/src/chrome/browser/devtools/devtools_sanity_browsertest.cc?rcl=ffad65b369389b624a7a609553ea59861cf7b897&l=2169

sky, do you remember any problems with OOPIFs and content::WaitForChildFrameSurfaceReady in mus?

The Viz folks know more with this code.
+kylechar

There would have been problems with OOPIFs/WaitForChildFrameSurfaceReady() before the mus/viz split happened. How that code works in mus changed totally after the split and it's the same as production now.

I'd imagine it's a real failure now. If whatever renderer isn't sending CompositorFrames then WaitForChildFrameSurfaceReady() will timeout in the RunLoop.

 Issue 820659  has been merged into this issue.

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

commit fdc9e0f16924f9f1a339de76b8f876ebe1988bfc
Author: Trent Apted <tapted@chromium.org>
Date: Mon Mar 12 07:16:38 2018

Disable flaky SitePerProcessDevToolsSanityTest.InputDispatchEventsToOOPIF

TBR=dgozman@chromium.org

Bug: 819285
Change-Id: I632bb2bf537037e7f69a22013f67d89d6549ab9d
Reviewed-on: https://chromium-review.googlesource.com/958645
Reviewed-by: Trent Apted <tapted@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542437}
[modify] https://crrev.com/fdc9e0f16924f9f1a339de76b8f876ebe1988bfc/chrome/browser/devtools/devtools_sanity_browsertest.cc

So mus_browser_tests are no more.

However this test is currently failing for me on Linux, in normal browser_tests.

It seems to constantly time out while waiting on its page navigation, before waiting on surfaces. In:
  content::TestNavigationManager::WaitForDesiredState