I wonder if we should switch the WS to use client_id of 1 instead of 0 with this change? That would reduce confusion when looking at FrameSinkId(0, 5) where it could be (1) a FrameSinkId provided by a client that hasn't been rewritten yet or (2) a WS FrameSinkId that doesn't need to be rewritten.

Requiring all client-ids to be non-zero sounds reasonable to me.

Sg, basically +1 to every client's client_id (i.e. WS 1, WM 2, ...)? If everyone agrees, I can file another bug and make the change in WS.

Right now only display-root and wm-display-root are created by WS and they don't receive events (right?) so there shouldn't be confusion in CompositorFrameSinkSupport tho?

This is inconsistent with what content does, and so I worry about having two different code paths here. 0 client ID means "browser process" in non-mus which happens to also work because that's the only place where we use aura in non-mus.

This keeps code consistent between Mus and non-Mus by leaving it at 0.

Right. None of the other clients would actually refer to the frame sinks for the ws, either in CompositorFrame or HitTestData. But if you print out the id, it would not be obvious whether this is a real fs id, or an fs id that still needs to be fixed/updated. So the purpose here would be to make it easier (or less confusing) when debugging.

I think we are taking about the client id assigned to clients by the window server. This shouldn't affect content.

None of the other clients see the windows with a client id == 0. But if you're referring to code in mus, then ya, that code sees client id == 0. It shouldn't be a problem to updated that, but will mean a bunch of id changes to tests.

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

Migrating Proj-Mustash-Mus to components Internals>Services>WindowService and Internals>Services>Ash

Cleaning up old Proj-Mustash labels.