I don't understand. Can't the mus::Window have a collection of surface instance? Do we have a mus::WindowSurface class?

Which side of the musgpu/musws split does the surface association exist on? i.e.: do we need to have mojom to schlep the surface collection for a window beween processes?

We do have a mus::WindowSurface. You can create one from any process at any time. A WindowSurface is just a pretty wrapper around two MessagePipes. mus::Window has an AttachSurface method and you pass in a "WindowSurfaceBinding" (the other side of the two MessagePipes).

We have security checks in the window server (mus-gpu in the future) that verify that a CompositorFrame can only refer to surfaces within its subtree. Otherwise, you could have a mus::Window go full screen and embed Ash SysUI for example which is BAD as it could phish the user.

Thus, apps must declare the surfaces they're using and "attach/bind" them to a Window meaning "This window is allowed to reference these surfaces".

Thanks for the explanation. I was confused by WindowSurface vs WindowSurfaces. 

Surface ids all come from the privileged process (browser process today).

AKA DelegatedFrameHost knows about its renderer, receives surfaces from there, assigns ids to them. Ditto for RenderWidgetHostViewChildFrame. The priviledged process knows the hierarchy of these things too, right?

So why do we have apps declaring surfaces to the mus process? Shouldn't it have the information it needs? We could just give different namespaces to subtrees or something, then it would be impossible to refer to a surface id in another tree or ancestor?

Using different namespaces could solve the problem, yes.

fsamuel@, sadrul@ We decided to resolve this a different way right? By the "inherited window event dispatching"?

Re-open if you disagree.

Yea, I think it's fair to close this. Although some of the discussion here is useful.