Issue metadata
Sign in to add a comment
|
Regression: Join WiFi overlay opens multiple times with black bordered shadow when we clicked on it multiple times |
||||||||||||||||||||||
Issue descriptionChrome Version:69.0.3464.0/10805.0.0 dev channel Gnawty,Spring & Falco OS: Chrome OS What steps will reproduce the problem? (1)Sign into user >> In OOBE /ubertray >> go to Network section (2)Open any Join WiFi overlay >>now again open the same Join WiFi overlay (3)Repeat Step 2 and observe(please refer video) Actual: Same overlay opens again and again (multiple times)with black bordered shadow when we clicked on it multiple times Expected: Same overlay shouldn't open again and again when we select it multiple times. This is a Regression issue as same is working fine in M-65 Note: 1.Issue is seen from M-66 2.Issue is not seen in Linux,Windows OS
,
Aug 15
Agreed that this dialog should be a singleton, but this doesn't seem urgent; will fix for 70.
,
Sep 6
Punting to 71
,
Oct 3
,
Dec 7
To fix this I am keeping track of these dialogs and if a matching dialog already exists (e.g. WiFi config or VPN config), I am calling: SystemWebDialogDelegate::dialog_window()->Focus() This successfully focuses the window and brings it to the front, however it can not be interacted with. I noticed that with the current behavior when there are multiple always-on-top windows, only the topmost can be interacted with. sky@ / ooshima@ - is that WAI, or a bug? If it is WAI, I'm not sure that we want to allow more than one always-on-top window, but in that case it is not clear what the best behavior is if the user attempts to open a different dialog. Note: We switched from system modal dialogs to always-on-top windows some time ago because some of these configuration dialogs are involved and it is helpful for users to be able to copy/paste date to the dialogs. We could reconsider that decision however.
,
Dec 7
Note: I just discovered that the behavior I described in comment #5 only applies to the login screen. After login the always-on-top windows behave as expected, as does Focus(). So I assume that is a bug. +jdufault@
,
Dec 7
It should be possible to open multiple always on top windows. You should be able to activate the one you picked and interact with. However, always on top is or normal windows, and won't work in lock state. That's probably why it's misbehaving? We probably can simply make it modal in lock/login state, because it's less useful to be normal window in that state?
,
Dec 7
So, it turns out that the problem is that we are making SystemWebDialogDelegate dialogs modal when SessionManager::session_state() != ACTIVE. I think this was intended to handle the lock screen, but in the login screen the behavior is confusing, so I am going to fix that to only use modal dialogs when session_state == LOCKED. (In practice, i am not aware of any system dialogs that can be opened in that state anyway).
,
Dec 10
,
Dec 10
Actually, system dialogs need to be modal in the login screen to show on top of the login screen overlay. Unfortunately, focusing a modal dialog that is not the frontmost dialog creates a situation where no dialogs can be correctly interacted with. The best we can do is to avoid opening multiple identical dialogs in the login screen.
,
Dec 12
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f7c8453dcd2ea5ed44852a76823375537c6668a5 commit f7c8453dcd2ea5ed44852a76823375537c6668a5 Author: Steven Bennetts <stevenjb@chromium.org> Date: Wed Dec 12 21:49:44 2018 SystemWebDialogDelegate: Track instances This CL tracks SystemWebDialogDelegate instances so that derived classes can check for an existing instance and focus that instead of opening a new instance. Bug: 855344 Change-Id: I688f2e09bd280a511d4ab53463beccfdd10f5371 Reviewed-on: https://chromium-review.googlesource.com/c/1366793 Reviewed-by: James Cook <jamescook@chromium.org> Reviewed-by: Toni Baržić <tbarzic@chromium.org> Commit-Queue: Steven Bennetts <stevenjb@chromium.org> Cr-Commit-Position: refs/heads/master@{#616061} [modify] https://crrev.com/f7c8453dcd2ea5ed44852a76823375537c6668a5/chrome/browser/ui/webui/chromeos/bluetooth_pairing_dialog.cc [modify] https://crrev.com/f7c8453dcd2ea5ed44852a76823375537c6668a5/chrome/browser/ui/webui/chromeos/bluetooth_pairing_dialog.h [modify] https://crrev.com/f7c8453dcd2ea5ed44852a76823375537c6668a5/chrome/browser/ui/webui/chromeos/bluetooth_pairing_dialog_browsertest-inl.h [modify] https://crrev.com/f7c8453dcd2ea5ed44852a76823375537c6668a5/chrome/browser/ui/webui/chromeos/internet_config_dialog.cc [modify] https://crrev.com/f7c8453dcd2ea5ed44852a76823375537c6668a5/chrome/browser/ui/webui/chromeos/internet_config_dialog.h [modify] https://crrev.com/f7c8453dcd2ea5ed44852a76823375537c6668a5/chrome/browser/ui/webui/chromeos/internet_detail_dialog.cc [modify] https://crrev.com/f7c8453dcd2ea5ed44852a76823375537c6668a5/chrome/browser/ui/webui/chromeos/internet_detail_dialog.h [modify] https://crrev.com/f7c8453dcd2ea5ed44852a76823375537c6668a5/chrome/browser/ui/webui/chromeos/system_web_dialog_browsertest.cc [modify] https://crrev.com/f7c8453dcd2ea5ed44852a76823375537c6668a5/chrome/browser/ui/webui/chromeos/system_web_dialog_delegate.cc [modify] https://crrev.com/f7c8453dcd2ea5ed44852a76823375537c6668a5/chrome/browser/ui/webui/chromeos/system_web_dialog_delegate.h
,
Dec 12
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rkalavakuntla@chromium.org
, Jun 22 2018