GNOME Bugzilla – Bug 486445
Don't change focus to new window if it is concealed
Last modified: 2008-07-14 20:46:02 UTC
If a window is created AND the entire area of the window is concealed, then focus should remain as it was before, AND attention hint is set on the window. Apparently a new window can only be concealed if there is an existing window that has 'always on top' set. However, possibly a window might set a 'appear always under other windows'. In those cases the new window (if fully concealed) should also not get focus. Use case: * You watch a movie in a fullscreen + always on top MPlayer * Some window pops under the movie * You suddenly cannot pause the movie anymore with 'space'. It goes to some window you cannot even see. Usually activating whatever button might have the default focus of that window Same happens with games btw, although I think those don't have always on top set (so metacity should prevent windows from being seen even).
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report. http://svn.gnome.org/viewvc/metacity?view=revision&revision=3358 (Please let me know how you get on with this and then I'll backport it to 2.20.)
Fix doesn't work properly: * If you switch between workspace with the fullscreen program, it will make the other programs behind it 'blink' * file-roller popup usually pops up 'centered' (horizontal+vertical of screen).. if focus is prevented, it doesn't seem to popup in the center * I think it doesn't work if many windows popup within max 1 second (e.g., if Firefox restarts and loads the 5+ windows again)
testing..
This needs to be fixed before 2.21.1 releases; I hope to work on it this weekend.
For your three problems: 1) Well spotted; this was a slip I made in the condition of the "if" statement: the stacking adjustment, etc., should never be made for windows being mapped after their first mapping. http://svn.gnome.org/viewvc/metacity?view=revision&revision=3386 2) File-roller doesn't come up centred for me anyway, but perhaps I'm doing it wrongly. 3) I'm not sure how to reproduce this. Let me know whether the new fix works for you.
We at the Pidgin project received a bug report that we think may be related to this fix. If a conversation window is open on the non-active workspace and you double-click that buddy (or chat) in the buddy list, we call gtk_window_present() on the conversation window. Previously, that would bring it to your current workspace and focus it. Now, you get a taskbar item on your current workspace that blinks. If you click it, it changes to the other (previously non-active) workspace and focuses the window. Do you think that was caused by this change? If so, was that intentional? Thanks for any help you can provide!
That wasn't the intention of this bug. I think the behaviour you describe was changed in another bug ( IIRC bug 482354).