I think we won't be able to fix it. This is due to window manager on Linux.

Trent, could you remind us what the problem is?

aura::Window on Linux defaults to a kind of simulated window, which doesn't map to an X11 resource. As you say, window managers (particularly tiling window managers) like to grab all X11 windows and "manage" them, sometimes in unexpected ways.

A possible fix may be to use Widget::InitParams::TYPE_MENU for the profile chooser. This works for the Chrome app menu (i.e. it _can_ extend past the parent window boundary), and the Profile chooser is quite menu-like in its UX. However, other things may break/change. E.g. The fade-in/fade-out animation may change without other tweaks.

 Widget::InitParams::TYPE_BUBBLE is hardcoded at the level of BubbleDialogDelegateView. As an experiment I tried to change it to Widget::InitParams::TYPE_MENU but then everything crashed because TYPE_MENU doesn't have a client_view(). 

I'm not sure where the code creating a real X11 window is. Adding some bubble owners.
Does extending DialogDelegate with a method IsOSWindowRequired sounds like a decent path to explore?

The code for creating the X11 window is in DesktopWindowTreeHostX11. DesktoWindowTreeHostX11 is used on linux if DesktopNativeWidgetAura is created for a Widget. The decision as to whether DesktopNativeWidgetAura is used is made by the function ChromeViewsDelegate::CreateNativeWidget which also calls to CreateNativeWidget in c/b/ui/views/native_widget_factory. It looks like if in the init params you do not set a parent you will get a DesktopNativeWidgetAura. Of course that is likely to result in a bunch of other subtle things happening.