Created attachment 361322 [details]
Description of problem:
In strict mode, metacity will not focus nor place windows on top of the stack when run from a terminal.
But with sloppy focus, if the newly mapped window falls under the mouse pointer, it's yes not focused while it should be, forcing the user to leave and re-enter the window with the pointer to focus it.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Make sure the options are set as follow (e.g. use gconf-editor)
/apps/metacity/general/focus_new_windows = strict
/apps/metacity/general/focus_mode = sloppy
2. Run a terminal
3. Move the pointer outside of the terminal window, keeping the terminal focused (sloppy focus)
4. Launch different apps from the terminal
When a window is mapped under the mouse pointer, it's not focused.
Window should not be focused in strict mode + sloppy focus *unless* the pointer is already in the window.
Historically, newly mapped window would be placed on top of the stack and focused by metacity.
Therefore, the EnterNotify events ought to be ignored when mapping new windows. This is the purpose of the sentinel window used in meta_window_show() in src/window.c:
/* Prevent EnterNotify events in sloppy/mouse focus from
* erroneously focusing the window that had been denied
* focus. FIXME: This introduces a race; I have a couple
* ideas for a better way to accomplish the same thing, but
* they're more involved so do it this way for now.
But the "strict" mode changed that as the windows would appear unfocused and not on top of the stack. This does not work with sloppy/mouse focus mode because the user would have then to leave and re-enter the window behind the cursor to focus it in sloppy/mouse mode.
Therefore, in "strict" mode, where the window is not necessarily focused, the sentinel should not be used so that the EnterNotify event is not ignored and the window focused as expected when it falls under the mouse pointer.
This is what the proposed patch does.
This doesn't quite make sense to me. My understanding of:
meta_prefs_get_focus_new_windows () != META_FOCUS_NEW_WINDOWS_STRICT
Is that it means:
Don't focus new windows, even if a terminal previously had focus
So it really has nothing to do with what happens when a window is denied focus and pops up under the mouse pointer. (focus_new_windows == STRICT is not at all the same as the old strict_pointer_mode patch we had.)
The current behavior is pretty consistent - it's the same thing that happens as when you alt-tab away from the focused window - you have to click or enter-leave to get the focus back there.
In the absence of strict_pointer_mode, the only other behavior I could think of would be to make it so that when the pointer window isn't the focus window any mouse motion (maybe with a few pixels of slop) resets the focus window. That would require polling the mouse position continually - though that isn't all that expensive when done 10 times a second.
There are 3 patches scheduled for 5.5 that I think should make a patch in this area unnecessary.
Bug 530261 - Handle windows under pointer without focus better
With this improvement, if a window is mapped under the pointer but
doesn't get the focus, or if a window steals focus from the window
under the pointer, then the user can return focus to the window
under the pointer with a small motion of the mouse. The idea here
is to be "best of both worlds" - to avoid most of the inconvenience
when the window under the mouse loses focus without the breakage
of keyboard navivation produced by the old strict_pointer_mode patch
Bug 530262 - Allow configuring windows that should not be focused
Even with the above patch, its still slightly inconvenient when
focus is stolen away. This focus stealing is typically from old
legacy applications. A GConf key is added to allow specifying
windows that should never steal focus - for example it could be
(and (equals class "Myemailprog") (equals name "New email from *"))
to disable email notification windows with matching titles from stealing
Bug 530263 - Allow configuring new windows to be always placed on top
One of the biggest annoyances with focus stealing prevention is if
an application gets focus stealing prevented and is mapped underneath
and the user doesn't notice it or has to go down to the taskbar to
find unbury it. This adds a configuration option so new windows are always
mapped on top, even when they don't get focused.
I'd suggest, if possible, using 'smart' new window mode, not 'strict' new window mode. The config key in bug 530262 should be a better way of working around focus being stolen away from a terminal than the 'strict' new window mode.
I'm going to mark this as a duplicate of bug 530261, since it's most similar to that.
*** This bug has been marked as a duplicate of bug 530261 ***