In Mash, ash owns the non-client frame and the caption buttons within. Pointer events in the non-client area are handled by Ash. Chrome draws the client area, including the tabstrip, on top of the ash window, but doesn't draw anything over the frame. The problem is that custom browser themes need to draw either a color or an image, depending on the theme, but if Chrome does this right now it paints over the ash-provided caption buttons. (In addition to custom themes, we also aren't drawing the right color for incognito frames, see bug 704942 .)
Possible approaches:
1) change the Z-order so that the ash top level window draws on top of the client window. The only thing it should draw is the caption buttons.[i] Chrome is responsible for drawing the (possibly themed) background of the frame, as it is in classic ash.
2) send sufficient theme-related data over mojo to ash so that ash can draw the themed frame. This probably requires a lot of code duplication from BrowserFrameHeaderAsh.
3) make Chrome wholly responsible for the frame, making caption buttons usable from Chrome (currently they reach into ash::Shell for a couple things, but that should be possible to mojo-ify. For example, use of TableModeClient instead of TabletModeController).
Also note that Chrome creates extra caption buttons for some hosted app windows, including a back button and an app menu icon. Interaction with these is handled by Chrome, not Ash, so they can probably stay on Chrome side. Only tricky bit would be making sure that layout works even though some caption buttons are in one process and some in the other.
[i] This probably breaks something, but I couldn't immediately figure out how to test this as I had difficulty locating the code that controls client (chrome) vs. window manager (ash) window stacking.
Comment 1 by jamescook@chromium.org
, Apr 25 2018