Focusing a modal dialog does not allow interaction |
||||
Issue descriptionOn Chrome OS, showing a modal dialog does not prevent interaction with the system menu, so more than one modal dialog may be visible at once. calling aura::Window::Focus() on an dialog window where GetModalType() != ui::MODAL_TYPE_NONE does not bring the focused window to the front. It does however take focus away from the frontmost dialog window. As a result, neither window can be interacted with. We should either: a) Prevent opening more than one modal dialog. b) Make Focus() a no-op on a dialog window that is not frontmost. c) Make Focus() bring the dialog window to the front. My preference would be c over b over a, depending on the relative difficulty. This is not blocking anything, just something of a landmine for the next unsuspecting developer :)
,
Dec 11
src/ash/system (is there another?) Repro: 1. On the login screen, open the system menu / quick settings / whatchamacallit by clicking on the status area / bottom-right-corner widget. 2. Select the network item > add wifi icon. This opens a modal dialog since we are in the login screen. 3. Open the same UI > network item > (any connected network) This opens another modal dialog. Observe: The top dialog can be dragged, but the dialog underneath it can not be interacted with. Changing the code to call Focus() on the second (bottom) window will remove focus from the first window, but will not allow interaction with the second window.
,
Dec 12
There are different "modal" types. System modal should prevent interaction with the system menu, while app modal does not. I assume it's using app modal? > It does however take focus away from the frontmost dialog window. As a result, neither window can be interacted with. Focused window doesn't have to be topmost, but it has to be activatable. Mabye there is a race due to being in lock container. Let me take a quick look what's causing the issue.
,
Dec 12
The code in question uses ui::MODAL_TYPE_SYSTEM: https://cs.chromium.org/chromium/src/ui/base/ui_base_types.h?type=cs&sq=package:chromium&g=0&l=39
,
Dec 14
,
Jan 4
So, my guess is that this was regressed when the container for system menu has been moved to lock scren cotnainer. Before that, a modal dialog should have prevented interaction with the system menu.
,
Jan 7
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7a1a79b471b50faef61ae28ff988aa91a56a4128 commit 7a1a79b471b50faef61ae28ff988aa91a56a4128 Author: Mitsuru Oshima <oshima@chromium.org> Date: Mon Jan 07 18:55:36 2019 System modal dialog should block shelf/status/system tray. Bug: 914133 Test: covered by unit tests. Also tested manually, including OOBE. Change-Id: I6bbb76092aecbca8c378d050187c958bc8fa9450 Reviewed-on: https://chromium-review.googlesource.com/c/1396794 Commit-Queue: Mitsuru Oshima <oshima@chromium.org> Reviewed-by: Steven Bennetts <stevenjb@chromium.org> Cr-Commit-Position: refs/heads/master@{#620401} [modify] https://crrev.com/7a1a79b471b50faef61ae28ff988aa91a56a4128/ash/root_window_controller.cc [modify] https://crrev.com/7a1a79b471b50faef61ae28ff988aa91a56a4128/ash/wm/system_modal_container_layout_manager_unittest.cc [modify] https://crrev.com/7a1a79b471b50faef61ae28ff988aa91a56a4128/chrome/browser/chromeos/input_method/candidate_window_controller_impl.cc
,
Jan 7
Please file a bug and assign to me if you find an issue with system modal dialog. |
||||
►
Sign in to add a comment |
||||
Comment 1 by jamescook@chromium.org
, Dec 11