Shelf is clickable when system modal is shown |
||||
Issue descriptionWhen system modal is shown, the shelf should not be clickable and should be greyed out. But after adding '--show-md-login', the shelf is clickable under system modal, and one can open the launcher (but the launcher icons are still not clickable). This is because we add shelf container under lock_screen_related_containers here[1], while the system modal is in non_lock_screen_containers. Can we do a reparenting of the shelf container to lock_screen_related_containers when session state becomes locked, and still put it under non_lock_screen_container otherwise? Could you give some suggestions? [1] https://cs.chromium.org/chromium/src/ash/root_window_controller.cc?l=879
,
Oct 13 2017
Hi, could you provide any suggestions?
,
Oct 13 2017
System modal windows should be put into SystemModalContainer [1], which is above ShelfContainer. The screenshot seems suggesting this somehow does not happen as Shelf is on top of the modal shadow. Can you check which container is the modal dialog put into? [1]: https://cs.chromium.org/chromium/src/ash/wm/container_finder.cc?rcl=d1a7f3f12e7748e6eeed536703972f2f79f1570e&l=90
,
Oct 13 2017
Note https://cs.chromium.org/chromium/src/ash/root_window_controller.cc?rcl=c2c3cdfcc68121becde093a244a5cdf89a552faf&l=873 which puts the shelf into lock related containers (which is above shelf) if show-md-login is present
,
Oct 13 2017
Now it makes sense. :) Think we should initially put shelf container in non_lock_screen_container and move it when we are on login/lock screen. Check out WallpaperController::OnSessionStateChanged [1]. Could we do something similar? [1]: https://cs.chromium.org/chromium/src/ash/wallpaper/wallpaper_controller.cc?rcl=064a1f3a5974481ae060d829beeb82661f922e80&l=321
,
Oct 16 2017
xiyuan@, thanks! It's slightly different from the example, because shelf container is not the only child of its parent. So when we do re-parenting, we have to store the index of the shelf container in the old parent, so that when it's re-parented back, it can maintain the original order. But if other containers are also re-parenting, it can introduce bugs... Or is it worthwhile to create both lock/non-lock shelf containers and do the re-parenting in the shelf widget level? So that shelf widget is the only child of both containers. I can't tell if it's worthwhile.
,
Oct 16 2017
Taking a step back. The problem happens because we put the login/lock shelf inside ShelfWidget. Is it possible to make it part of views-based login/lock screen instead?
,
Oct 16 2017
Yes.. it seems that the login/lock shelf should have been made as part of login/lock/screen. In that way it cannot reuse ShelfLayoutManager, but it seems everything else is cleaner. I'll investigate this and if we can't make it, I incline to close this issue as won't fix.
,
Nov 27 2017
,
Oct 4
Issue 824051 has been merged into this issue.
,
Oct 4
,
Jan 7
@wzang given your comment #8 of > 1 year ago, is this still relevant? Or should it be closed? Thanks! |
||||
►
Sign in to add a comment |
||||
Comment 1 by wzang@chromium.org
, Sep 20 2017Labels: -Pri-3 M-63 OS-Chrome Pri-1