fwiw, this is consistent with how network config dialog behaves, so if we change mobile setup behavior, we might want to consider doing the same for network config dialogs.

Thanks, Toni. When you say network config boxes, what is an example of that?

For example, click on "Add network" button, or on a non-open network in the detailed system tray

The "System" dialogs in CrOS include:
* Primary/initial network configuration (password, certificates, user names, etc) from the system tray.
* Secondary network configuration in the login screen (APN, IP Address, etc). (After login this is handled in the Settings UI).
* Bluetooth pairing from the system tray.
* Mobile setup / activation.
* Assistant opt-in.

Originally these dialogs were modal, but that doesn't allow data from other pages to be copy/pasted or even viewed.

We made these "Always on Top" so that the dialogs would not get "lost" behind other windows.

I would be reluctant to change that behavior for these dialogs, and I think that we should keep them consistent (at least all of the network/bluetooth configuration dialogs). They can always be closed and re-opened if there is a reason for the user not to respond to them immediately.

yeah, IMHO, keeping these dialogs (including mobile setup) in foreground makes sense.

The primary motivation for filing this bug was that feedback app window was shown beneath the mobile activation dialog. Maybe it would make more sense to show the feedback app window as "always on top", too.

That makes sense to me for the feedback window.

That's super helpful context Steven, thanks for that.

I agree that it makes sense for all the network/Bluetooth configurations windows to remain "always on top," as these items don't have a dedicated icon in the system tray when they are active, so it would be easy for a user to lose track.

I just did some provisioning window tests myself (needed to find a cold SIM), and it appears that it too lacks a dedicated icon. For consistency's sake then, it makes sense to maintain the same always-on-top treatment for provisioning.

That being the case, it appears that the feedback window *does* have a dedicated icon in the system tray when active, so it's less likely that a user will lose track of the window - at the risk of having generated a bunch of noise for nothing, I'd argue that the current behavior then is WAI across the board, and I don't see a super compelling reason to change the feedback window behavior.

SGTM. It's a little awkward and not entirely obvious, so definitely worth discussing I think, and always good to have fresh perspectives :)

Agreed! Thanks, all.