New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 755303 link

Starred by 1 user
Status: Fixed
Owner: ----
Closed: Feb 2018
Cc:
█ fsam...@chromium.org
sadrul@chromium.org
mustash-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocking:
issue 775030



Sign in to add a comment

StartupMetricsTest.ReportsValues (browser_tests) hangs with --mus

Project Member Reported by sky@chromium.org, Aug 14 2017 
The portion of the test causing problems is waiting for "Startup.BrowserMainToRendererMain." This is never set when running in --mus. RenderWidget::DidMeaningfulLayout() is part of the chain responsible for initiating the IPC to Chrome. This calls to QueueMessage, which adds a  cc::SwapPromise to RenderWidgetCompositor. Once the promise runs the IPC is sent. With --mus the SwapPromise is never fulfilled so that the test hangs.

It seems like with --mus the SwapPromises are pushed (LayerTreeImpl::PushPropertiesTo) to a LayerTreeImpl that never ends up processing the promises.

Comment 1 by sky@chromium.org, Oct 11 2017 

Fady, I can take this on if you give me some hints as to what the right thing to do is.

Comment 2 by sky@chromium.org, Nov 6 2017

Blocking: -740655 731255

Comment 3 by jonr...@chromium.org, Nov 6 2017

Blocking: 775030

Comment 4 by dtapu...@chromium.org, Nov 9 2017

Components: Internals>MUS

Comment 5 by fsam...@chromium.org, Nov 21 2017 

This isn't a viz bug right? This is a mus bug?

Comment 6 by sky@chromium.org, Nov 28 2017 

Fady: I think this is more of compositor frame sniffing, right?

Comment 7 by sadrul@chromium.org, Dec 6 2017

Blocking: -731255
I don't think this fails anymore with --mus.

Comment 8 by jonr...@chromium.org, Feb 15 2018

Status: Fixed (was: Untriaged)

Comment 9 by lafo...@chromium.org, Feb 26 2018

Components: -Internals>MUS Internals>Services>WindowService
►

Sign in to add a comment