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 124798 - window under mouse pointer is not always focused when switching workspace
window under mouse pointer is not always focused when switching workspace
Status: RESOLVED NOTABUG
Product: metacity
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2003-10-16 21:58 UTC by Dams
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.0



Description Dams 2003-10-16 21:58:45 UTC
Description of Problem:
first : i dont use click-to-focus feature.
If i dont move the mouse while switching workspace
 using keyboard shorcut, the focused window in the
one under the mouse pointer.
Now, if i start moving the mouse before i press
the keyboard shortcut, then press the keyboard
shortcut to switch workspace, the window1 under
the mouse pointer is focused, but as i keep moving
the mouse, the mouse pointer leave this window1
and enter another one (window2). I stop moving the
mouse then, but the window2, which is under the
mouse pointer, is _not_ focused. window1 is still
focused.

To focus window2, i have to mouse-leave it and
mouse-enter it.

I dont see any good and valid reason to break the
'window under mouse pointer is focused' invariant
so far and i consider this as a bug.

How often does this happen? 
I can reproduce this anytime you ask me to do it.
But to reproduce this you have to act non-slowly.

Additional Information:
I use metacity(0:2.6.2-1).i386 under Fedora Core
0.95 (up-to-date).
Comment 1 Havoc Pennington 2003-10-17 01:17:55 UTC
See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107155

The ChangeLog entry introducing this behavior is:

2003-05-29  Rob Adams  <robadams@ucla.edu>

	Use a new property _METACITY_SENTINEL to eliminate a race
	condition that causes focus to behave badly with sloppy/mouse
	focus when lots of windows are mapped/unmapped, such as with a
	workspace switch.  The EnterNotify events on a display are ignored
	until the PropertyNotify sent after all the window maps is
	received.  This is a fix for #110970.

So see bug #110970 for more details. Though that bug doesn't mention 
the more basic bug I don't think, which is that if window A is focused
on workspace 1, and you switch to workspace 2 and back to workspace 1,
window A could become unfocused. I think we had a couple other bugs
about that.

There's no way to fix your bug without regressing these other bugs,
that I know of. The WM can't read minds. ;-) But if someone can think
of a way I welcome their patch.

I'm not willing to maintain the invariant strictly by warping the
pointer around because I believe that cure is worse than the disease.

Mouse focus simply doesn't work right with keyboard navigation,
inherently.
Comment 2 Dams 2003-10-17 01:59:07 UTC
Rhaaa.. 
This is a poorly designed behaviour.. i'm really fed up with all this
behaviour things in metacity i dont like and i cannot configure..
Please ! Pretty Please ! Make this damn window manager customizable !!
Hide theese options in gconf, i dont care but i want to be able to
have the behaviour i like ! It's very irritating. Grr. 
Comment 3 Havoc Pennington 2003-10-17 03:05:44 UTC
Just use a configurable window manager - there are only, say, 500 of
them out there. Including at least half a dozen with decent GNOME/KDE
support.

I don't have time to fix all the bugs in a _not_ configurable WM, let
alone the triple or quadruple bug count I'd get with traditional
configuration levels.

If you really can't live with any other WM, fix a few dozen of the
bugs in here and then you can add a config option. ;-)
Comment 4 Dams 2003-10-21 20:21:24 UTC
When i switch back from fullscreen with xine/mplayer the xine/mplayer
video output window is not focused, even if the mouse is under the
window. The window under the xine/mplayer window is focused instead.
Is this related to the sentinel thing ? Is this still normal ??
Comment 5 Havoc Pennington 2003-10-22 02:39:55 UTC
That sounds unrelated/unexpected. Though it could be caused by funky
hacks in xine/mplayer conceivably; maybe they unmap themselves or
something.
Comment 6 Elijah Newren 2004-09-02 04:52:30 UTC
Fixing this bug without regressing the other bugs is a one line patch:

Index: keybindings.c
===================================================================
RCS file: /cvs/gnome/metacity/src/keybindings.c,v
retrieving revision 1.100
diff -p -u -r1.100 keybindings.c
--- keybindings.c       26 Aug 2004 00:59:12 -0000      1.100
+++ keybindings.c       2 Sep 2004 04:46:35 -0000
@@ -2680,6 +2680,7 @@ process_workspace_switch_grab (MetaDispl
                       "Activating target workspace\n");

           meta_workspace_activate (target_workspace);
+          meta_workspace_focus_default_window (target_workspace, NULL);

           return TRUE; /* we already ended the grab */
         }

However, I think we can do even better and I will be looking into it.  Also, the
other bug Havoc mentions (focusing some window, switching workspaces, then
switching back, and having a different window be focused) was fixed in bug 135810.
Comment 7 Elijah Newren 2004-09-03 19:07:47 UTC
See also bug 123803, which this is basically a duplicate of.