GNOME Bugzilla – Bug 695200
Switching apps while a combobox open makes the parent window toplevel and always-visible
Last modified: 2018-04-14 23:54:32 UTC
win32-only issue, steps to reproduce: * Run the combobox example in gtk-demo * Open the combobox * Alt+Tab to switch to another open application * Alt+Tab to go back to the original gtk-demo window Now the gtk-demo window is in the toplevel and always-visible, on top of any other application. The root cause of this issue seems to be that the GDK_WINDOW_TEMP window of the open combobox does not get closed when we switch to another application; it actually stays on top of the application you switch to. Once we go back to our GTK+ application, we end up re-stacking the windows (gdkevents-win32.c, ensure_stacking_on_activate_app()), and during the re-stacking the main window gets re-stacked below the GDK_WINDOW_TEMP window of the combobox, which implicitly moves the main window to the toplevel group as the open combobox window is in that group. That makes our main window be always-visible and in the toplevel, quite annoying.
Created attachment 238106 [details] [review] Possible hack - not the best one A quick hack for this is to avoid restacking below GDK_WINDOW_TEMP windows, as done in this patch. This avoids the final issue (window toplevel and always visible), but this is possibly not the best way to go (so just adding the patch for reference now). We should possibly instead make sure that no GDK_WINDOW_TEMP window is open when we re-activate. This actually is the case with menus: you open a menu, Alt+Tab and when you cycle back to your application the menu is not open. Same should apply to the GDK_WINDOW_TEMPs created by an open combobox, and if we do so, when re-activating there will be no GDK_WINDOW_TEMP to cause the issue.
Created attachment 238151 [details] [review] Fix for the issue This fix is not win32 specific, it instead tries to solve the issue by completely avoiding to have combobox's GDK_WINDOW_TEMP windows open when the grab is lost, same logic as done by the menu. The patch applies on top of gtk-2-24, but can prepare a patch for git master with the same logic if it looks good. I'll obsolete the previous patch for now as well, as it was more a hack than a real fix.
Changing component to GtkComboBox; as the root issue is not win32-specific.
Review of attachment 238151 [details] [review]: This patch looks right to me
Created attachment 238196 [details] [review] Same patch, for git master
Review of attachment 238196 [details] [review]: ok
Patches added to gtk-2-24 and git master, resolving as fixed.
Reopening and moving to the win32 component, I think that the patch in comment #1 is actually quite valid, and does fix the underlying issue. Widgets or apps may not be as well behaved as hiding TEMP windows when focusing out, so the same problem would happen later when you focus in on these. What that code tries though is to ensure the right stacking per the EWMH spec, and that WS_EX_TOPMOST group all TEMP windows pertain to ensures they're kept on top of anything else. Not checking those windows there is most safe, as the restacked window will still be kept below anyway.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new