Yeah, it's Hadi's CL:

    Add system modals to the proper container in mus+ash.
    
    System modal windows should be added to kShellWindowId_SystemModalContainer so
    we get effects like gray background for them.
    
    BUG= 702747 
    
    Review-Url: https://codereview.chromium.org/2759643003
    Cr-Commit-Position: refs/heads/master@{#458533}

Repro on Linux desktop:

* Run chrome --login-manager
* Click on system tray > network item > join other (the Wi-Fi arc with the little plus sign on it)

The dialog should appear, but instead the system tray menu doesn't close and there is no dialog. Hitting Ctrl-Alt-Shift-S shows the output above.

The Wi-Fi dialog container for mash is set in SystemTrayClient in chrome:
https://cs.chromium.org/chromium/src/chrome/browser/ui/ash/system_tray_client.cc?q=system_tray_client&sq=package:chromium&l=211

I suspect classic ash avoids this problem because it directly sets a Widget parent.

I think the problem is ash::mus::WindowManager::OnWmSetModalType calls into ash::wm::GetDefaultParent() which calls into GetSystemModalDialogContainer(). This places any dialog without a transient parent into the under-the-lock-screen SystemModalContainer.

https://cs.chromium.org/chromium/src/ash/mus/window_manager.cc?q=window_manager.cc&sq=package:chromium&l=279
https://cs.chromium.org/chromium/src/ash/wm/container_finder.cc?sq=package:chromium&l=47

The parenting/transient window code was added a long time ago in https://chromiumcodereview.appspot.com/15690015/ to fix a crash when an extension background page opens a modal dialog when the screen is locked. I wonder if there is a better fix for that issue.

I also wonder if a more systematic fix would be to have a Widget or aura::window property for "show at lock screen", false by default. It might let us get rid of the explicit containerid mus window property. I suspect that's a medium size refactor and a little risky from a security/privacy perspective. If you think that's the right solution reassign this bug back to me and I can dig into that approach, since I added the containerid thing.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/65326efd379044957448a6846bf05a5f96f3ed46

commit 65326efd379044957448a6846bf05a5f96f3ed46
Author: Scott Violet <sky@chromium.org>
Date: Fri Jul 21 00:09:56 2017

chromeos: makes changing modal type not reparent window

Ash in mash mode was reparenting system modal dialogs. Problem is the
code was using GetDefaultParent(), which makes some assumptions that
are not always right for Chrome code. This fixes the issue by making
it so that when the modal type changes ash doesn't change the parent.

I suspect we will have to revisit this at some point, but this is the
easy fix for now.

BUG= 743064 
TEST=covered by test

Change-Id: I21b097b5ad2c52e153b0880ec33c96e950fad624
Reviewed-on: https://chromium-review.googlesource.com/580631
Reviewed-by: James Cook <jamescook@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#488503}
[modify] https://crrev.com/65326efd379044957448a6846bf05a5f96f3ed46/ash/mus/window_manager.cc
[modify] https://crrev.com/65326efd379044957448a6846bf05a5f96f3ed46/ash/mus/window_manager_unittest.cc