Seems like a special case of surface sync. fsamuel@: can you triage?

Yes, it is. I'm still working on a prototype of the fallback behavior (need to make changes to SurfaceLayer, SurfaceLayerImpl, SurfaceDrawQuad, serializtion/deserialization code, SurfaceAggregator, etc), get cc folks to sign off on design and review all the patches. This is 2 weeks to 1 month out.

The way this will work is when you create a window that will host an embedded client, then you also ship along with it a LocalSurfaceId to the client. The parent will immediately embed the LocalSurfaceId.

If the CompositorFrame for the parent arrives before the child, then the Display Compositor will note the unresolved dependency and mark the frame as "pending". The frame will continue to be pending until the child submits a frame or a deadline hits. Once one of those two conditions is met, the display compositor will "activate" that frame.

Alternatively, we can wait until SetSurfaceInfoFromServer to display the window decorations. This has the problem of dealing with an unresponsive child as well so then the parent would need to implement its own deadline mechanism. I think it makes sense to bake this machinery in the display compositor so that clients don't all need to reinvent the wheel over and over again.

I've turned on surface synchronization by default in both Mushrome and Mus+Ash. This should now be fixed.