Bug 523784 - Window not focused with sloppy/mouse mode and strict new window mode
Summary: Window not focused with sloppy/mouse mode and strict new window mode
Keywords:
Status: CLOSED DUPLICATE of bug 530261
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: metacity
Version: 5.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Owen Taylor
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-16 16:32 UTC by Olivier Fourdan
Modified: 2013-03-04 02:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-10 19:03:28 UTC


Attachments (Terms of Use)
Proposed patch (947 bytes, patch)
2009-09-16 16:32 UTC, Olivier Fourdan
no flags Details | Diff

Description Olivier Fourdan 2009-09-16 16:32:22 UTC
Created attachment 361322 [details]
Proposed patch

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):

metacity-2.16.0-12

How reproducible:

100% reproducible

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
  
Actual results:

When a window is mapped under the mouse pointer, it's not focused.

Expected results:

Window should not be focused in strict mode + sloppy focus *unless* the pointer is already in the window.

Additional info:

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:

----B<---------------------------------------------------------------------
         /* 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.
          */
         meta_display_increment_focus_sentinel (window->display);
----B<---------------------------------------------------------------------

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.

Comment 1 Owen Taylor 2009-09-28 21:51:10 UTC
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.

Comment 2 Owen Taylor 2009-11-10 19:03:28 UTC
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
  set to:

   (and (equals class "Myemailprog") (equals name "New email from *"))

  to disable email notification windows with matching titles from stealing
  focus.

  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 ***


Note You need to log in before you can comment on or make changes to this bug.