GNOME Bugzilla – Bug 124095
Wrong window receives focus after closing a spawned window
Last modified: 2007-01-08 03:16:13 UTC
When Pan (for Windows... haven't checked Linux, but I assume it's not there) creates a new Window (for example, the "Browse" interface of the "Save Attachments As..." dialog box), and the user dismisses that window, the wrong window receives the focus as the spawned window closes. Steps to reproduce (in Windows): 1. Select a group of messages. 2. Right click on the messages and choose "Save Attachments As..." 3. Click "Browse" 4. Click "Ok" 5. Click "Save" Expected behavior: The message attachments begin downloading, and the main window (the window with the header list) should receive the focus. Actual/obseved behavior: The message attachments begin downloading, but a window from a different program receives the focus. The window which receives the focus is the window that had the focus just before Pan received the focus. In other words, if I am using AIM, and I switch to the main window of Pan, then perform the above steps, AIM will receive the focus instead of Pan. In this case, I am referring to "focus" as meaning the window that is in the forefront.
The same behavior can be found using different steps as well (bringing up different windows). For example, choosing "News Servers" or "Posting Profiles" from the "Tools" menu, the "Open"ing one of the entries, clicking "Ok" and then "Close" will have the same effect. The trick seems to be that the window that the main Pan window spawns must spawn it's own window for there to be a problem.
Can't reproduce under Linux; this appears to be a gtk2-windows problem? Tor: the dialog in question is a vanilla gtk dialog created with dialog = gtk_dialog_new_with_buttons (_("Pan: Save As"), GTK_WINDOW(Pan.window), GTK_DIALOG_DESTROY_WITH_PARENT, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_SAVE, GTK_RESPONSE_OK, NULL);
Could this be the same issue as bug #107319 ?
Yes, 107319 sounds like a specific case of this general (mis)behavior.
Created attachment 29919 [details] [review] Patch against gtk+-2.4.1 that sort-of fixes this bug The attached patch goes some way toward fixing the bug. The right window will get the focus, but only after the wrong window has had it for a fraction of a second. The resulting flicker is not too noticable, and it's certainly better than not workign at all.
(This bug is not assigned correctly; reassigning to component owner - win32 maint)
Created attachment 57565 [details] [review] Improved version of the above patch The previous patch caused bug #314896 by also acting on skip-taskbar windows, such as popup menus. The focus was set to the hidden window used as the transient owner, removing focus from the application window. This patch checks that the owner window is not the hidden window used for skip-taskbar windows before setting it active.
*** This bug has been marked as a duplicate of 112404 ***