Widget::InitParams::mus_properties does not work for setting parent using NativeWidgetAura |
|||||||
Issue descriptionThe DCHECK in NativeWidgetAura[1] will trigger if showing the views-based lock screen in mash (--show-md-login --mash). The Widget and Widget::InitParams values are initialized in LockWindow[2]. Views-based lock screen initialization happens in the ash process, whereas the webui lock screen is initialized from the chrome process (and thus webui lock uses through DesktopNativeWidgetAura). NativeWidgetAura should understand Widget::InitParams::mus_properties so that calling code can be more uniform in how it passes initialization state. 1: https://cs.chromium.org/chromium/src/ui/views/widget/native_widget_aura.cc?l=152 2: https://cs.chromium.org/chromium/src/ash/login/ui/lock_window.cc?l=17 Owner to sky@ for triage.
,
Sep 8 2017
Removing UI>Shell as triage process. (see go/cros-ui-triage-process)
,
Feb 26 2018
,
Apr 24 2018
Migrating from Proj-Mustash-Aura to components Internals>Aura
,
Aug 3
This bug has an owner, thus, it's been triaged. Changing status to "assigned".
,
Aug 15
I don't believe the original issue is relevant anymore as ash now always uses NativeWidgetAura. However, James's comment #2 has been talked about quite a bit. I'm kicking this over to James to decide if there is anything to do here.
,
Aug 16
I don't think this is relevant any more. I think we still need the DCHECK, as we've talked about the importance of plumbing around some kind of context so we know which aura::Env* to use when creating aura::Windows. jdufault, we don't use webui lock screen anymore, right? I thought we switched to views lock screen a long time ago. I still see the code for webui lock in the codebase, so I'm not sure.
,
Aug 16
Right, views lock has been used for many milestones now and we no longer maintain the webui one. We're planning on cleaning up the webui lock and webui login code at the same time since they are highly interdependent.
,
Aug 16
Great, sounds like this is obsolete then. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by jamescook@chromium.org
, Aug 29 2017Labels: Proj-Mustash-Aura
Regardless of how we resolve this bug, we might want to get rid of this DCHECK: void NativeWidgetAura::InitNativeWidget(const Widget::InitParams& params) { // Aura needs to know which desktop (Ash or regular) will manage this widget. // See Widget::InitParams::context for details. DCHECK(params.parent || params.context); That dates back to the Win 8 Metro Ash implementation, where it was vital to know which Windows desktop to use for a new window. These days we can just put the window on the ash::Shell::GetRootWindowForNewWindows().