Issue 701626 link

Starred by 0 users

Issue metadata

Status:	Archived
Owner:	█ fsam...@chromium.org Last visit > 30 days ago
Closed:	Mar 2017
Cc:	rjkroege@chromium.org sadrul@chromium.org jamescook@chromium.org sky@chromium.org mustash-bugs@google.com
Components:	Internals>Compositing Internals>Services>WindowService
EstimatedDays:	----
NextAction:	----
OS:	Chrome
Pri:	1
Type:	Bug
mustash-1 Proj-Mustash VerifyIn-60 VerifyIn-61

New windows show up empty

Project Member Reported by sadrul@chromium.org, Mar 15 2017

Issue description

When chrome --mash launches, it starts with the chrome browser window, and a quick-launch window. If I close both windows, then press shift+escape to open the task manager, or press ctrl+n to open a new chrome browser window, then the window frame shows up, but the window content does not show up. If I drag on the window caption, and start moving the window, then it shows up.

I initially thought (and panicked!) that this was caused by the overdraw fix in crrev.com/456910 However, I can reproduce this behaviour on crrev.com/456909. This feels like an issue with the display compositor? Assigning to fsamuel@ for triage.

Comment 1 by fsam...@chromium.org, Mar 15 2017

I see this more often with my surface sync prototype but I have begun suspecting that this isn't a bug in my code. 

I need to debug more but my current guess is there's a race between an app requesting a size, and the window manager deciding on a size for a window. I'll poke at this more tomorrow. Thanks for filing this Sadrul!

Project Member

Comment 2 by bugdroid1@chromium.org, Mar 18 2017

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

commit 8f0964617b1d3e6abdc4f61e8f1d4b8bf0f6c672
Author: fsamuel <fsamuel@chromium.org>
Date: Sat Mar 18 03:25:11 2017

Preserve FrameSinkSourceMapping nodes that have path to root

In the Mus window server, every ServerWindow has a corresponding unique
FrameSinkId whether or not it has a CompositorFrameSink. Some (most)
ServerWindows do not submit CompositorFrames because they are local windows
within some ancestor that does submit a CompositorFrame.

We keep the FrameSinkSourceMapping in sync with the ServerWindow hierarchy
to simplify reparenting of windows across displays.

However, prior to this patch, if a FrameSinkSourceMapping loses all its
children and does not have a CompositorFrameSink (a SurfaceFactoryClient)
registered, then the node will be removed. When the window server adds
a child to the ServerWindow corresponding to the deleted FrameSinkSourceMapping
that child becomes orphaned and an appropriate BeginFrameSource does
not propagate to it. This manifests when all windows are closed in Mus+Ash
and a new window is opened. That window will not show any content because
it will not receive BeginFrames.

This CL fixes this issue by preserving the FrameSinkSourceMapping as long
as it has a BeginFrameSource.

BUG= 701626 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2750223005
Cr-Commit-Position: refs/heads/master@{#457948}

[modify] https://crrev.com/8f0964617b1d3e6abdc4f61e8f1d4b8bf0f6c672/cc/surfaces/surface_manager.cc
[modify] https://crrev.com/8f0964617b1d3e6abdc4f61e8f1d4b8bf0f6c672/cc/surfaces/surface_manager_unittest.cc