GNOME Bugzilla – Bug 126489
Correctly handle app/group modal dialogs
Last modified: 2020-11-06 20:05:49 UTC
Occasionally I'll have for example a browser window open in more than one workspace. Sometimes an application modal dialog will pop up in another workspace, so that the browser window I'm working with becomes mysteriously nonfunctional. This could happen because, for example, a web page has a timer that pops up a javascript confirm, which is a modal dialog, while I'm on the other workspace. Possible ways to deal with this: 1) remove the rule in meta_window_new to put transient dialogs with their parent windows on their workspaces 2) use some sort of new EWMH hint to detect the case where a user tries to interact with a window waiting on a modal dialog in another workspace, and move the dialog. 2 would be cool, but I propose we go with 1 for now at least.
(I hate javascript.) Isn't this a browser bug? If the dialog is application modal, the WM_TRANSIENT_FOR hint should not be set to an application window. The app modal window's hints should include: _NET_WM_WINDOW_TYPE = _NET_WM_WINDOW_TYPE_DIALOG _NET_WM_STATE = _NET_WM_STATE_MODAL And either: WM_TRANSIENT_FOR = None (0x0), WM_TRANSIENT_FOR = the root window of its screen, or no WM_TRANSIENT_FOR hint at all. Unless I've read the wm-spec incorrectly, any of those 3 sets makes the window a group modal dialog, which is for now the same as an application modal dialog. When the window is recognized as app modal, it should stay above all the application's other windows on all workspaces. That may require that it appears on more than one, but not necessarily all, workspaces. The first suggestion is lossy, unless all transients are omnipresent. If they're all omnipresent, then clutter explodes. The second suggestion would require setting hints or sending messages correctly to work around existing incorrect hints. The app author would probably get it wrong both ways.
The problem may well be that metacity just doesn't have code to do it. Maybe we should move application modal dialogs to the current workspace when you switch to any workspace that has an application window on that workspace? Or put it on all workspaces that have an application window open? We also need to refuse to focus windows that have a modal dialog open.
The patch in bug 164716 has given Metacity support for parent-window-modal dialogs (it refuses to focus windows with such a transient dialog and instead focuses the dialog; it will also warp that dialog to the correct workspace at that time). However, it doesn't handle app-modal. Also, Havoc's comments from bug 164716 are relevant to part of this bug as well: "GTK does support only-modal-for-parent-window but nobody uses it because people are using modality as a programming crutch rather than a UI feature." I think that's at least half the problem with this bug, though we should support dialogs that are truly app-modal (i.e. that match the definition(s) Gregory gave) as well.
*** Bug 123566 has been marked as a duplicate of this bug. ***
Also, we should check to see if we need to unminimize a dialog if it's app-modal (which I don't think is relevant for the parent-window-modal case, since then modal dialogs are only minimized with their parent). See bug 123566 for specific case rationale...
gtk+ bugs that may be relevant: bug 109638 (explains how to make gtk windows be parent-window-modal instead of app-modal), bug 124525 (add gtk+ support for how to hint to the window manager about group transient vs. parent-window transient), and bug 133043 and bug 133044 (about having gtk+ itself do the rejection of of the focus on the parent windows instead of having the WM do it).
*** Bug 307875 has been marked as a duplicate of this bug. ***
Bug 307875 points out a separate case where our handling of group modal dialogs is buggy--when the window is launched we can get stacking and focus incorrect if we don't correctly know the modal relationship. (For a while, this even resulted in modal windows being obscured and users potentially believing their apps were frozen/broken). See bug 307875 comment 11 and 12.
*** Bug 312338 has been marked as a duplicate of this bug. ***
Chris provides a good example in bug 312338 of an app that sets the group-modal hint correctly and causes the app to be (surprisingly to the user) unusable on other workspaces--that app is nautilus. Anyway, between that and the eclipse I'm going to bump up the priority and severity.
*** Bug 335354 has been marked as a duplicate of this bug. ***
Okay, I'm putting this on all relevant milestones because I really suck for not having fixed this yet.
It's also worth pointing out that meta_window_foreach_ancestor doesn't handle group modal dialogs and, in fact, is only robust against certain kinds of infinite loops. See also bug 332493 about some related issues in libwnck (though, it'll be filed as a new libwnck bug at some point as I suggested there...).
"Okay, I'm putting this on all relevant milestones because I really suck for not having fixed this yet.". *Poke*. Any progress on this? :)
Hmm...I said that before I really knew how much time my wife's student teaching and other graduation requirements would take (requiring me to watch the kids more and other things), before I knew I was going to GUADEC (or that it'd actually make it harder to get Gnome development done than easier), or that I'd be mentoring a SoC student, or knew how much time my dissertation would take out of my schedule. :-( No progress on this has been made; but I think you can expect it for 2.18...
removing gnome target as said by marnanel.
Moving things to focus component. Sorry for spam.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.