Currently ChromeOS exclusively uses NativeWidgetAura. For mash/OopAsh the browser side needs to use DesktopNativeWidgetAura. There is a fair amount of changes going into code that is based on NativeWidgetAura in the browser side for ChromeOS (BrowserFrameAsh and related classes). To date we have a separate Mus class (based on DesktopNativeWidgetAura). This means changes need to be replicated in two places, and as a result the two are hugely out of sink. We need to figure out a way to have only one class that is used going forward.
I see two possibilities here:
1. Figure out how to create a DesktopWindowTreeHost that is backed by an aura::Window.
2. Have the browser side use the WindowService for any windows it creates.
1 would likely require significant changes to aura and related classes. It would also likely entail duplicating a fair amount of logic we already have in the WindowService. This work would be throw away once we have oopash.
For these reasons we should investigate 2. It will likely mean we need to a 'context' any where an aura::Window is created (so that WindowPortMus can be created).
Comment 1 by sky@chromium.org
, May 30 2018