After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695200 - Switching apps while a combobox open makes the parent window toplevel and always-visible
Switching apps while a combobox open makes the parent window toplevel and alw...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.24.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-03-05 10:41 UTC by Aleksander Morgado
Modified: 2018-04-14 23:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Possible hack - not the best one (1.29 KB, patch)
2013-03-05 10:49 UTC, Aleksander Morgado
none Details | Review
Fix for the issue (2.41 KB, patch)
2013-03-05 18:03 UTC, Aleksander Morgado
committed Details | Review
Same patch, for git master (2.30 KB, patch)
2013-03-06 12:36 UTC, Aleksander Morgado
committed Details | Review

Description Aleksander Morgado 2013-03-05 10:41:41 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.
Comment 1 Aleksander Morgado 2013-03-05 10:49:20 UTC
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.
Comment 2 Aleksander Morgado 2013-03-05 18:03:21 UTC
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.
Comment 3 Aleksander Morgado 2013-03-05 18:03:57 UTC
Changing component to GtkComboBox; as the root issue is not win32-specific.
Comment 4 Matthias Clasen 2013-03-06 11:39:20 UTC
Review of attachment 238151 [details] [review]:

This patch looks right to me
Comment 5 Aleksander Morgado 2013-03-06 12:36:42 UTC
Created attachment 238196 [details] [review]
Same patch, for git master
Comment 6 Matthias Clasen 2013-03-12 11:18:04 UTC
Review of attachment 238196 [details] [review]:

ok
Comment 7 Aleksander Morgado 2013-03-12 11:55:07 UTC
Patches added to gtk-2-24 and git master, resolving as fixed.
Comment 8 Carlos Garnacho 2013-07-10 17:39:01 UTC
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.
Comment 9 Matthias Clasen 2018-02-10 04:53:52 UTC
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.
Comment 10 Matthias Clasen 2018-04-14 23:54:32 UTC
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