New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 855344 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Dec 12
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regression: Join WiFi overlay opens multiple times with black bordered shadow when we clicked on it multiple times

Project Member Reported by rkalavakuntla@chromium.org, Jun 22 2018

Issue description

Chrome 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

 
ACtual.mp4
8.7 MB View Download
Expected.mp4
9.8 MB View Download
Black bordered edges.jpg
4.8 MB View Download
actual.jpg
3.6 MB View Download
Components: UI>Settings
Labels: -Pri-1 -M-69 M-70 Pri-2
Agreed that this dialog should be a singleton, but this doesn't seem urgent; will fix for 70.

Labels: -M-70 M-71
Punting to 71

Labels: -M-71 M-72
Cc: osh...@chromium.org sky@chromium.org
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.



Cc: jdufault@chromium.org
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@
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?

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).


Status: Started (was: Assigned)
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.

Project Member

Comment 11 by bugdroid1@chromium.org, 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

Status: Fixed (was: Started)

Sign in to add a comment