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

We hit the OOPIF case on ToT for some websites in smoothness.top_25_smooth telemetry tests. I believe it's the Google account sign-in iframes that open in an OOPIF. Example stack trace is here:

[110115:110115:1110/134310.243584:FATAL:host_frame_sink_manager.cc(183)] Check failed: frame_sink_manager_impl_. 
#0 0x7fce1ad85da7 base::debug::StackTrace::StackTrace()
#1 0x7fce1adae101 logging::LogMessage::~LogMessage()
#2 0x7fce0d14e3eb viz::HostFrameSinkManager::CreateCompositorFrameSinkSupport()
#3 0x7fce188d1b1d content::RenderWidgetHostViewChildFrame::CreateCompositorFrameSinkSupport()
#4 0x7fce188d1a66 content::RenderWidgetHostViewChildFrame::RenderWidgetHostViewChildFrame()
#5 0x7fce188d181f content::RenderWidgetHostViewChildFrame::Create()
#6 0x7fce186ab4dc content::RenderFrameHostImpl::CreateRenderFrame()
#7 0x7fce189ecccc content::WebContentsImpl::CreateRenderFrameForRenderManager()
#8 0x7fce186c4736 content::RenderFrameHostManager::InitRenderFrame()
#9 0x7fce186c3c0a content::RenderFrameHostManager::CreateRenderFrame()
#10 0x7fce186c1b94 content::RenderFrameHostManager::CreateSpeculativeRenderFrameHost()
#11 0x7fce186c1221 content::RenderFrameHostManager::GetFrameHostForNavigation()
#12 0x7fce186c10e1 content::RenderFrameHostManager::DidCreateNavigationRequest()
#13 0x7fce18675eaf content::FrameTreeNode::CreatedNavigationRequest()
#14 0x7fce1869b3a5 content::NavigatorImpl::OnBeginNavigation()
#15 0x7fce186a64f8 content::RenderFrameHostImpl::OnBeginNavigation()
#16 0x7fce186a613c _ZN3IPC8MessageTI33FrameHostMsg_BeginNavigation_MetaNSt3__15tupleIJN7content22CommonNavigationParamsENS4_21BeginNavigationParamsEEEEvE8DispatchINS4_19RenderFrameHostImplESA_vMSA_FvRKS5_RKS6_EEEbPKNS_7MessageEPT_PT0_PT1_T2_
#17 0x7fce186a015a content::RenderFrameHostImpl::OnMessageReceived()
#18 0x7fce188a362e content::RenderProcessHostImpl::OnMessageReceived()
#19 0x7fce19f53c85 IPC::ChannelProxy::Context::OnDispatchMessage()
#20 0x7fce19f56a42 _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12ChannelProxy7ContextEFvRKNS3_7MessageEEJ13scoped_refptrIS5_ES6_EEEFvvEE3RunEPNS0_13BindStateBaseE
#21 0x7fce1ad86661 base::debug::TaskAnnotator::RunTask()
#22 0x7fce1adb8220 base::internal::IncomingTaskQueue::RunTask()
#23 0x7fce1adbc1ef base::MessageLoop::RunTask()
#24 0x7fce1adbc575 base::MessageLoop::DeferOrRunPendingTask()
#25 0x7fce1adbc816 base::MessageLoop::DoWork()
#26 0x7fce1adbe3da base::(anonymous namespace)::WorkSourceDispatch()
#27 0x7fce0fea3e04 g_main_context_dispatch
#28 0x7fce0fea4048 <unknown>
#29 0x7fce0fea40ec g_main_context_iteration
#30 0x7fce1adbe133 base::MessagePumpGlib::Run()
#31 0x7fce1adbbade base::MessageLoop::Run()
#32 0x7fce1adef5f4 base::RunLoop::Run()
#33 0x557103cf0a0e ChromeBrowserMainParts::MainMessageLoopRun()
#34 0x7fce18537e72 content::BrowserMainLoop::RunMainMessageLoopParts()
#35 0x7fce1853b9bb content::BrowserMainRunnerImpl::Run()
#36 0x7fce185337ca content::BrowserMain()
#37 0x7fce18eed23f content::RunNamedProcessTypeMain()
#38 0x7fce18eedcbc content::ContentMainRunnerImpl::Run()
#39 0x7fce1b29b573 service_manager::Main()
#40 0x7fce18eec602 content::ContentMain()
#41 0x5571038191cc ChromeMain
#42 0x7fce0e389f45 __libc_start_main
#43 0x557103819029 <unknown>

 Issue 783924  has been merged into this issue.

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

commit 20d137071b906f9c595ad6483d239e8e8d1a922d
Author: kylechar <kylechar@chromium.org>
Date: Wed Nov 15 19:01:26 2017

viz: Fix RenderWidgetHostViewChildFrame with --enable-viz.

Don't create CompositorFrameSinkSupport with --enable-viz, since CFs are
submitted directly to viz. Also check to make sure that there is a view
for RenderWidgetHostImpl before getting FrameSinkId from it.

Bug:  778751 
Change-Id: I74fed71516cbd1f89bb40529ed34bb6343880f53
Reviewed-on: https://chromium-review.googlesource.com/771534
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516771}
[modify] https://crrev.com/20d137071b906f9c595ad6483d239e8e8d1a922d/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/20d137071b906f9c595ad6483d239e8e8d1a922d/content/browser/renderer_host/render_widget_host_view_child_frame.cc
[modify] https://crrev.com/20d137071b906f9c595ad6483d239e8e8d1a922d/content/browser/renderer_host/render_widget_host_view_child_frame.h

This all works AFAIK.

ArcAccessibilityHelperBridgeBrowserTest.PreferenceChange is failing viz_browser_tests on the mojo FYI bot:

https://ci.chromium.org/buildbot/chromium.fyi/Mojo%20ChromiumOS/26460

[13715:13715:0130/085242.012898:FATAL:host_frame_sink_manager.cc(225)] Check failed: frame_sink_manager_impl_.
#0 0x000003e89dcc base::debug::StackTrace::StackTrace()
#1 0x000003ea3fdc logging::LogMessage::~LogMessage()
#2 0x000005fa2681 viz::HostFrameSinkManager::CreateCompositorFrameSinkSupport()
#3 0x000005f69034 aura::LayerTreeFrameSinkLocal::BindToClient()
#4 0x00000304424d exo::SurfaceTreeHost::SurfaceTreeHost()
#5 0x000003039052 exo::ShellSurfaceBase::ShellSurfaceBase()
#6 0x00000303778e exo::ShellSurface::ShellSurface()
#7 0x000001c6ba1e exo::test::ExoTestWindow::ExoTestWindow()
#8 0x000001c6bc46 exo::test::ExoTestHelper::CreateWindow()
#9 0x000001391d2f arc::ArcAccessibilityHelperBridgeBrowserTest_PreferenceChange_Test::RunTestOnMainThread()
#10 0x0000044cfbc5 content::BrowserTestBase::ProxyRunTestOnMainThreadLoop()
#11 0x000003fbd9d9 ChromeBrowserMainParts::PreMainMessageLoopRunImpl()
#12 0x000003fbc76d ChromeBrowserMainParts::PreMainMessageLoopRun()
#13 0x000001983328 chromeos::ChromeBrowserMainPartsChromeos::PreMainMessageLoopRun()
#14 0x000002731fa1 content::BrowserMainLoop::PreMainMessageLoopRun()

Could this bug be the reason?

(I think this is the last test preventing the bot from being green.)

Different issue, nothing CrOS specific is expected to work with viz_* tests. I'm actually not sure why viz_browser_tests are running on the Mojo CrOS FYI trybot at all?

+penghuang@ FYI

We had them there before we had a Linux FYI bot to use.

We haven't looked to supporting Arc yet, so we should likely just disable this test.

But that seems like a new failure tied to exo work. Could you file a separate issue for it and send to penghuang@ who has been working in that space?