GNOME Bugzilla – Bug 767052
Wayland: Iconifying a modal dialog makes the app unusable
Last modified: 2016-06-01 08:07:12 UTC
Description: When using modal dialogs, gtk+ will mskr the parent window insensitite and not accept any user interaction. So if the user iconify a modal dialog alone (which is possible in Wayland), the application becomes unusable. Moreover, since the dialogs do not show up in either the preview pane nor the alt-tab list in gnome-shell, there is no way for the user to de-iconify the dialog, so the applications is basically dead. Steps to reproduce: 1. Select GNOME on Wayland session 2. set the minimize,maximize,close button layout: $ gsettings set org.gnome.desktop.wm.preferences button-layout ':minimize,maximize,close' 3. run gtk3-demo $ gtk3-demo --run spin-button 4. Iconify the demo dialog window (ie "Spin Buttons") using the iconify button on the title bar 5. Try to move, close, click the gtk3-demo window or even restore the spin button window Actual result: There is no apparent way to restore the spin button dialog nor to do anything in the gtk3-demo parent window, not even move it away. The gtk3-demo window appears to be dead to the user... Expected result: either the parent window gets iconified along with the modal, or better, the modal dialog should not have a iconify button at all.
Created attachment 328802 [details] [review] [PATCH] headerbar: do not show buttons for modals/transients GtkHeadeBar checks the window type hint to determine if the regular buttons such as menu, maximize or iconify should be visible in the header bar. However, an application may very well use a "normal" toplevel window and set it transient and modal afterwards. In such a case, the iconify button would remain visible, and the user can hide the window, but being a modal, the parent window would remain insensitive. Check for the window type, modality and transient relationship to decide whether or not the regular toplevel buttons should be visible in the header bar.
Review of attachment 328802 [details] [review]: ::: gtk/gtkheaderbar.c @@ +321,3 @@ + has_toplevel_buttons = (!gtk_window_get_modal (window) && + gtk_window_get_transient_for (window) == NULL && + gtk_window_get_type_hint (window) == GDK_WINDOW_TYPE_HINT_NORMAL); I could quibble with the variable name a bit - we _are_ adding the close button regardless of this, which I think would count as a 'toplevel button'. Maybe something like is_sovereign_window would be a bit more descriptive ?
Comment on attachment 328802 [details] [review] [PATCH] headerbar: do not show buttons for modals/transients attachment 328802 [details] [review] pushed to master as commit 7c397c6 with change as per comment 2 - headerbar: do not show buttons for modals/transients