Chrome modal conflict |
|||||||
Issue descriptionChrome Version : 55.0.2883.87 OS Version: URLs (if applicable) : calendar.google.com What steps will reproduce the problem? 1. Two chrome windows in separate profiles, both open on the desktop, mostly overlapping 2. Both have a calendar appointment that pops up a modal dialog simultaneously 3. The popup occurs What's visible: one modal popup on top of its window Other modal is presumably in front of its window and behind the front chrome window What is the expected result? You can cancel the visible popup. You can select non-chrome x-windows UI like xterms or the Unity start button. What happens instead of that? x-windows UI locks up almost completely. Clicking on most things is a no-op. Clicking on the visible popup makes it swell briefly as if to show that it isn't clickable until you handle the other modal popup, which it very effectively hides and prevents you from getting to. Needed to switch to non-graphical terminal mode and kill chrome to continue working. Please provide any additional information below. Attach a screenshot if possible. UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
,
Jan 3 2017
Added TE-NeedsTriageHelp as it seems not possible to triage from Te end.
,
Jan 4 2017
I'm not really sure where this belongs. +avi, you've been touching the modal dialog boxes recently (alert() in this case), any idea?
,
Jan 4 2017
kylechar@ and derat@ might know X11 and Linux platform stuff.
,
Jan 5 2017
It's happily been a long time since I've thought about this stuff, but I believe that most EWMH-following window managers will block interaction with the main window if a dialog has _NET_WM_STATE_MODAL set and is WM_TRANSIENT_FOR the main window. Interesting things happen if there are multiple modal dialogs (i.e. the WM is likely to screw this up). It'd be helpful to use xwininfo (possibly from an SSH session, if interaction with the desktop is blocked) to see exactly how Chrome is setting things up, in terms of which dialog blocks which window. But I suspect the answer is going to be "don't display multiple modal dialogs at once since the WM may do something unreasonable".
,
Jan 5 2017
I don't have much more to add, but I was able to reproduce something like this behaviour running Chrome 55.0.2883.87 in Cinnamon 2.6.13 after a few tries. The first Chrome window came to the foreground and displayed a modal dialog for the calendar entry. A few seconds later the second Chrome window came to the foreground without a modal dialog. The second Chrome window couldn't be interacted with, which makes sense if it was supposed to be displaying a modal dialog. However, I was able to close the second Chrome window using the window close button. The first Chrome window was still displaying the modal dialog which I was able to close as expected. I tried again and everything worked as expected. The first Chrome window displayed a modal dialog then the second Chrome window displayed a modal dialog. I was able to close the second Chrome windows modal, switch back to the first Chrome window and close it's modal. I think that supports "don't display multiple modal dialogs at once since the WM may do something unreasonable".
,
Jan 6 2017
+joone who did a lot of work on modal dialogs
,
Feb 16 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 13
Archiving old bugs that haven't been actively assigned in over 180 days. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks! |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ajha@chromium.org
, Dec 16 2016