This seems to be a bug in mutter. When the key is released, activateWindow from ui/main.js is called, which in turn calls window.activate, where window is a Meta.Window. The problem can be reproduced with other overlays as well: Open two windows, point the mouse at one window, press Alt-F2, point the mouse at the other window (nothing happens yet), press Esc, watch as the other window gets activated. This behaviour could be considered correct for other overlays though.

Created attachment 145251 [details]
mutter debug output

The attached image shows focus debug output from mutter. At the beginning of the output the terminal window running mutter is focussed. When Alt-F2 is pressed, the output up to the red line is produced. (Nothing unexpected there.) Now, while the run overlay is open, the mouse was moved to another Terminal window, which produces no output. When the overlay is closed again with Esc, the output after the red line is produced.

I think the line highlighted in yellow is interesting: The line directly above claims that the focus event is ignored, but then in the highlighted line the terminal is focussed due to a (the same?) enter notification.

the problem is that an invisible window gets interposed between the pointer and the windows when the run dialog or app switcher is up, and when you exit Alt-Tab, the pointer leaves that invisible window and re-enters the window underneath it where it was before, and so that window gets an "enter event", and so mutter selects it.

might be possible to have mutter ignore stage-to-application window crossing events?

Is there (In reply to comment #3)
> the problem is that an invisible window gets interposed between the pointer and
> the windows when the run dialog or app switcher is up, and when you exit
> Alt-Tab, the pointer leaves that invisible window and re-enters the window
> underneath it where it was before, and so that window gets an "enter event",
> and so mutter selects it.
> 
> might be possible to have mutter ignore stage-to-application window crossing
> events?

How would I go about doing this myself; where should I look? Somewhere in mutter I assume, but more definite pointers would be helpful.

(bump)

I can confirm this bug - using 2.29.0 (Ubuntu Karmic - ricotz repo, git 2010-03-19).

I confirm this too. Latest build from source.

With the latest Ctrl+Alt+Tab this "bug" has resurfaced even more. Basically, the Ctrl+Alt+Tag feature does not work with any other focus mode than "Click to focus".

To moderate a little: only if the mouse hovers the top-panel will it receive focus on pressing Ctrl+Alt+Tab and can be keyboard navigated.

I really like Gnome-Shell and have started using for day-to-day use, but I also really like to use the "sloppy" focus model.

Anyway, where could I look to make mutter ignore the stage-to-application window crossing events?

(In reply to comment #7)
> Anyway, where could I look to make mutter ignore the stage-to-application
> window crossing events?

I don't know. It's probably not a one-liner. It might require changes all over mutter.

Also confirmed, jhbuild from today.

*** Bug 647232 has been marked as a duplicate of this bug. ***

E17 has an option to let the mouse follow on alt-tab. Maybe that can be considered as a solution (or part thereof)?

(In reply to comment #11)
> E17 has an option to let the mouse follow on alt-tab. Maybe that can be
> considered as a solution (or part thereof)?

I could certainly live with that.

I have used gnome-shell with click-to-focus for quite a while now and I don't really remember why I so desperately needed the focus-follows-mouse in the first place. In fact, it might not work so well in gs because then the "window-menu" (the thing displaying the currently focused app just right of the "Activities"-button on the panel) would change frequently.

Also, if there are two windows open, one placed top-left and one bottom-right and the mouse is currently over the bottom-right one, it could be difficult to actually access the "window-menu" because one would have to move the mouse to the window-menu-button without moving over the top-left window (because then that'd get focus).

Right, focus follows mouse seems to be at odds with various design options in gnome-shell.

We could just mark the focus follows mouse option deprecated and unsupported (or even remove it entirely...) and be done with it.

I'd actually prefer that:
1) Allow focus-follow-mouse still but only give focus to a new window if the mouse is not moving (thus, one could still activate the "window-menu")
2) When using alt-tab, the mouse is moved to the window being activated upon activation of the window (thus, the affect of the mentioned bug would go away)

@Rua Matos: I'm not sure about various, so far I only count the top-left window menu (but perhaps there are more in the works or that I haven't noticed yet).

I'd much rather have to use a keyboard shortcut (even ctrl-alt-tab would do for now) to bring up that rarely used menu than I would sacrifice FFM.

(In reply to comment #13)
> We could just mark the focus follows mouse option deprecated and unsupported
> (or even remove it entirely...) and be done with it.

Please don't do that. I personally work mostly using the keyboard and when I have to use the mouse I am happy that I only have to move it and don't have to click (That said I miss a way to select one of the open windows when I press the meta key ;))…

Importance -> high, since this is a particularly high-visibility regression vs previous gnome versions. A decision needs to be made about whether focus-follows-mouse will be supported in any form in mainline. A decision to not support it in mainline should probably take into account whether or not this could be done via an extension.

Besides the convenience factor mentioned in comment #16, I often use focus-follows-mouse to be able to type in windows that are partially occluded by other windows.  In these circumstances, my windows are carefully placed and stacked so I can see exactly what I want to see in each one.  Moving the window to the top via click-to-focus or ALT-TAB would be disruptive to my workflow, as I would then have to re-establish the stacking order.

Getting focus-follows-mouse right is a deal-breaker for me.  As much as the rest of gnome-shell is appealing to me, I spent the past couple days switching to a different desktop environment exactly because the focus-follows-mouse behaviour in gnome-shell is not how it should be.  I am following this bug with the hope that it will be fixed, at which point I am looking forward to switching back.

So, please, do continue to support focus-follows-mouse (be it in mainline, or via extension)!

Please keep focus-follows-mouse (sorry for the ME TOO but there are no voting buttons...).

This is possibly related to the sloppy-focus bug I just raised https://bugzilla.gnome.org/show_bug.cgi?id=649776 .

Created attachment 187804 [details] [review]
implement mouse-follows-focus for alt tab dialog

I've had a go at implementing mouse-follows-focus (when alt tabbing) as suggested in Comment 11. This patch adds code whenever a window is activated from the alt tab dialog to move the cursor into the center-point of the new window, ensuring no other window will get focus.

It ought to be possible to replace the _ensure_mouse_within function with a signal (e.g "did-activate-window", and let extensions deal with it if needed. But I'd much rather see this fixed in core.

NOTE: this will affect users who have not enabled focus follows mouse. I presume that's unwanted, so further work will be needed to make this conditional on either the sloppy focus preference or a new preference.

*** Bug 649776 has been marked as a duplicate of this bug. ***

Patch applies and works as described for me.  Thanks; makes sloppy focus much more usable.

Does this also cover the opening of new windows via the "activities" view?

Florian: Nope, I didn't know that was a problem. It should be easy enough though.

I've also got a slightly modified patch (in progress) that only moves the mouse if it does not happen to already be within the target window. It's much less invasive, but could also be more surprising.

Created attachment 187905 [details] [review]
Alternative 1: mouse-jumps-to-focused window on alt tab

This patch obsoletes my first one. Functionality:

If mouse is outside activated window, move it to the center of the window. This should work on alt-tab switcher, as well as windows or applications activated from the activities view.

No action is performed if user's focus mode is set to "click" (the default). This is checked (in gconf) every time a window or application is focused, which may prove inefficient - but it needs to reflect the current state of the preference, and I'm not familiar enough with the gconf API to add some sort of hook to listen for they key change event.

I don't know how to get the same method to work on the ctrl-alt-tab dialog (to focus the top panel).

Still, I'd love for a mutter whiz to figure out how to make the invisible window *not* generate focus enter events when it disappears in the first place ;)

Created attachment 187953 [details] [review]
patches mutter to ignore leave events from non-window objects

Okay, time for me to stop talking ;)

I delved into mutter, and came up with a (tiny) patch that improves the situation massively. This is a patch to fix the problem on mutter's side, as opposed to my previous patches which have been against gnome-shell (so you need one or the other, not both).

It adds the X event serial to the ignore list when it sees a LeaveNotify event from a window that has no associated MetaWindow. This fixes the alt-tab, ctrl-alt-tab and overview modes, and doesn't require messing with the mouse pointer (which can be rather surprising).

I don't know enough about mutter to tell if this patch introduces other unwanted behaviour, but it seems like it should be relatively harmless. The only thing I've noticed so far is that mousing directly from the top panel to a window (with no pixels in between) will not focus the window. But that's a lot better than the existing situation.

A better solution would be to add some sort of window hint to the invisible (non-metacity) window to better target such things in the event handling code, but I looked into doing exactly that for a long time and completely failed to join the dots between gnome-shell, mutter, X, gdk, st and clutter. I'm not even sure if it's possible.

Comment on attachment 187953 [details] [review]
patches mutter to ignore leave events from non-window objects

Ah, excellent. This is very close...

First some style nitpicks:

>From: gfxmonk <tim@gfxmonk.net>

preferably you would use your real name there rather than "gfxmonk", although that's not absolutely required. Whatever you put there is probably what will end up in the list of contributors in the release announcement though.

>Subject: [PATCH] Ignore events that are the result of leaving a non-metacity
> window. This fixes focus-follows-mouse with the gnome-shell
> alt tab and overview mode activations

git commit style is to have a one-line summary, followed by a blank line, followed by a multi-line explanation. Beyond that, gnome-shell style is to end the description with a blank line followed by the URL of the corresponding bugzilla bug. See mutter's "git log" for examples

> 
>+
>   if (modified != None)

remove that added blank line

>+  if (event->type == LeaveNotify && window == NULL)
>+  {
>+    add_ignored_serial(display, event->xany.serial);

indent style is slightly off here; the "{" should be indented two spaces from the "if", and the next line indented two more spaces.



As for the details of the fix, I'm not totally sure that we want to ignore all non-MetaWindows... I think the event window here should be the window returned from XCompositeGetOverlayWindow(). Might want to check for that explicitly.

The code doesn't look like it should have any noticeable effect on click-to-focus users.

> The
> only thing I've noticed so far is that mousing directly from the top panel to a
> window (with no pixels in between) will not focus the window.

Try examining event->xcrossing.mode and event->xcrossing.detail. They probably differ in the two cases, since in the panel-to-window case you're moving the mouse out of the stage window, and in the alt-tab-to-window case, the stage window is changing shape so as to no longer include the mouse location.

Created attachment 188017 [details] [review]
patches mutter to ignore leave events from non-window objects (#2)

Thanks for the pointers, Dan.

I dug into your suggestion, and found the following results:

for the ALT TAB window disappearing, The two LeaveNotify events received are:

FOCUS: XCompositeGetOverlayWindow == window is 0
FOCUS: xcrossing mode == 0 and xcrossing.detail == 0
and
FOCUS: XCompositeGetOverlayWindow == window is 1
FOCUS: xcrossing mode = 0 and xcrossing.detail = 3


but for moving the mouse from the panel to a window:

FOCUS: XCompositeGetOverlayWindow == window is 0
FOCUS: xcrossing mode == 0 and xcrossing.detail == 3
and
FOCUS: XCompositeGetOverlayWindow == window is 1
FOCUS: xcrossing mode == 0 and xcrossing.detail == 4

for reference:
NotifyAncestor = 0
NotifyVirtual = 1
NotifyInferior = 2
NotifyNonlinear = 3
NotifyNonlinearVirtual = 4
EnterNotify = 7
LeaveNotify = 8

Based on this, I've attached a new patch that uses the condition:
	event->type == LeaveNotify &&
	XCompositeGetOverlayWindow(display->xdisplay, modified) == modified &&
	event->xcrossing.detail == NotifyNonlinear

Which seems to pinpoint the exact scenario of the alt-tab / overview overlay disappearing, while avoiding the panel-to-window event.

I've also fixed the style issues, cheers for pointing those out.

Comment on attachment 188017 [details] [review]
patches mutter to ignore leave events from non-window objects (#2)

ok, looks good although now that you're only look at the X window, not the MetaWindow, you can move the check up above the "window = ..." assignment, to go with the other add_ignored_serial() checks.

I'm going to assign to Owen for additional review before this actually goes in...

> ok, looks good although now that you're only look at the X window, not the MetaWindow, you can move the check up above the "window = ..." assignment, to go with the other add_ignored_serial() checks.

Good point. Do you need a new patch for that? Or can you /Owen just apply it up near the other checks? As long as it compiles, I don't see much chance of getting it in the wrong place.

Created attachment 188584 [details] [review]
Alternative 2: fix FFM without moving mouse; patches mutter to ignore leave events from non-window objects (#3)

Same as the previous patch, but (as suggested) moved near the other checks for ignoring events.

Applied these patches, and it seems to work.

One annoyance is that the cursor is visible after moving,  and it's RIGHT IN THE MIDDLE of what i'm working on. Would it be possible or desirable to hide the cursor when it's moved? Or move the cursor somewhere it's not in the way, like the center of the titlebar or something?

On further thought, the titlebar might not be ideal, since it would be easy to accidentally move the cursor up and into another window which would be focused. Hiding the pointer would be my ideal option (I think). "unclutter" might take care of this, but it doesn't seem to work under gnome-shell.

Jeremy: did you apply both patches? You should only need one or the other.

Perhaps I should have made it clearer that the two patches are attempting to solve the problem in different ways, but each is independent. I certainly think the most recent patch (for mutter) is the better approach, so the gnome shell patch should not be necessary. I didn't mark it as obsolete because it has not necessarily been replaced, the mutter patch is just a (better) way to fix the bug.

To address your concerns, part of the reason the mutter patch is better is that it has none of those problems - as far as I can tell, it behaves the same as mutter on gnome2 in relation to focus-follows-mouse.

*** Bug 651600 has been marked as a duplicate of this bug. ***

Indeed, that works great! Making me and a co-worker much happier and efficient gnome-shell users!

This helps a lot with the alt-tab dialog!
However, if you alt-tab to a window from another workspace and on the new workspace the mouse cursor is placed above another window than the one chosen, focus still goes to the one below the mouse pointer.

E.g. you have two windows tiled on workspace 2 and you are currently on workspace one with the mouse pointer located on the right of your screen. If you then alt-tab to the window being tiled to the left on workspace 2, you are switched to workspace 2 but due to the mouse being above the right window, that window gets focus instead of the left one.

It works very well for alt-tab between windows on the same workspace though, that already helps a lot.

*** Bug 652372 has been marked as a duplicate of this bug. ***

(In reply to comment #38)
> This helps a lot with the alt-tab dialog!
> However, if you alt-tab to a window from another workspace and on the new
> workspace the mouse cursor is placed above another window than the one chosen,
> focus still goes to the one below the mouse pointer.

I'm too lazy to test right now, but does the patch in bug 647706 help?

(In reply to comment #40)
> (In reply to comment #38)
> > This helps a lot with the alt-tab dialog!
> > However, if you alt-tab to a window from another workspace and on the new
> > workspace the mouse cursor is placed above another window than the one chosen,
> > focus still goes to the one below the mouse pointer.
> 
> I'm too lazy to test right now, but does the patch in bug 647706 help?

No, unfortunately that does not seem to make a difference.

*** Bug 653020 has been marked as a duplicate of this bug. ***

*** Bug 655802 has been marked as a duplicate of this bug. ***

3.1.3.1+git20110719.fccd6266-0ubuntu1~11.10~ricotz0

Are the patches invalid or have they simply not made it this far?

As far as I know, no patch has been committed. I recommend Alternative 2 (and it has been verified to work by a few in this thread) but nothing has been committed to master yet.

Is there anything blocking the acceptance of this patch? (does it need review or something?). It seems like it's been sitting here a while.

(In reply to comment #44)
> 3.1.3.1+git20110719.fccd6266-0ubuntu1~11.10~ricotz0
> Are the patches invalid or have they simply not made it this far?

I have no idea what this refers to. Being more verbose is welcome.

3.1.3.1+git20110719.fccd6266-0ubuntu1~11.10~ricotz0 is just an ubuntu version string of a packaged version from July 19th.

I think we're all just wondering what's stopping the patches in this bug from being committed, so we can stop manually patches our local builds to support it.

(In reply to comment #47)
> I think we're all just wondering what's stopping the patches in this bug from
> being committed

from comment 30: "I'm going to assign to Owen for additional review before this actually goes in"

Review of attachment 188584 [details] [review]:

The reason why this works is pretty much a coincidence. We have two nested windows - the compositee-overlay window and the stage window. When we reshape the stage window, we do it in two stages - we first change the shape of the stage, then we change the shape of the overview. So, in the first step, we generate a crossing from the stage window to the exposed overlay, and then a crossing from the exposed overlay to target window. But if the user moves the pointer, we get a direct crossing from the stage window to the target window.

(Note there's actually no reason at all we're changing the shape of the stage window - it just doesn't matter and is pointless.)

One possibility that would be less of a coincidence would be make add_ignored_serial() public to the internals of metacity (in display-private.h) and then just do that with XNextRequest() when reshaping the stage. This might require a larger number for the number of ignore-serials we save, since we have to save the from the point where make the X requests until the point we get the events back.

(Which also allows avoiding XCompositeGetOverlayWindow() in the metacity core which we want to avoid - it is a round trip, and also has the side effect of creating the window if it doen't exist.)

Special casing reshaping does require us to be sure that reshaping the overview window corresponds 1:1 to cases where we don't want to recompute focus. Have you checked that with your patch the behavior is right if you move the pointer when in the overview? After you leave the overview is the window under the pointer focused, or does the focus stick on the last window?

When leaving the overview, the window currently under the pointer is focused.

Nonetheless, this patch makes a huge difference towards making FFM usable. Considering how bad the feature works without the patch, can this be pushed for 3.2, and then deal with any bugs in the behavior as separate or follow-up issues?

> Considering how bad the feature works without the patch, can this be pushed for
3.2, and then deal with any bugs in the behavior as separate or follow-up
issues?

If it helps to have my input on this, I'd like that approach. To be honest, I have little idea how to do the things that Owen mentions w.r.t add_ignored_serial and friends, so unless somebody else makes a patch for that (which would be ace, btw!) it's not going to happen any time soon. It would therefore be completely broken for a long time, rather than just a bit broken for a long time (it's already been quite a while since this bug was opened).

(In reply to comment #51)
> > Considering how bad the feature works without the patch, can this be pushed for
> 3.2, and then deal with any bugs in the behavior as separate or follow-up
> issues?
> 
> If it helps to have my input on this, I'd like that approach.

I'm not taking this patch. Mutter is complex, and if we start putting code in that isn't right, but happens to work by coincidence, it will be impossible to maintain in the future.

It's conceivable that I might have time to write something better before 3.2, but it certainly would be better if someone who used focus-follows-mouse did!

(In reply to comment #52)
> (In reply to comment #51)
> > > Considering how bad the feature works without the patch, can this be pushed for
> > 3.2, and then deal with any bugs in the behavior as separate or follow-up
> > issues?
> > 
> > If it helps to have my input on this, I'd like that approach.
> 
> I'm not taking this patch. Mutter is complex, and if we start putting code in
> that isn't right, but happens to work by coincidence, it will be impossible to
> maintain in the future.
> 
> It's conceivable that I might have time to write something better before 3.2,
> but it certainly would be better if someone who used focus-follows-mouse did!

The complexity is making it less likely that someone will, though :(.

I guess it should be release-noted that "FFM doesn't work (see BZ #597190; patches very welcome)", right?

I have built a version of mutter with the latest patch so at least things can sort of work for some people for a little while:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3331875

I have not tested it yet.

Created attachment 195893 [details] [review]
focus-follows-mouse: ignore events generated when reshaping the stage

This is probably all you need, untested except for compilation.

====

* Export meta_display_add_ignored_crossing_serial()
* Add the serial for reshaping the stage
* Increase the size of the "ignored_serials" array a bit to
  try to avoid the possibility of losing serials from multiple
  reshapes happening close together.

I rebuilt the Fedora package with this patch applied and have run this for a
few hours. Looks good to me.

Likewise, this looks good here.

Me three, looks good to me.  My RPMs are here: https://koji.fedoraproject.org/koji/taskinfo?taskID=3341317

Thanks very much for this patch, previous patches, and all the consideration.

Looks good to me too, thanks Owen!

revisiting comment 38:
> However, if you alt-tab to a window from another workspace and on the new
> workspace the mouse cursor is placed above another window than the one chosen,
> focus still goes to the one below the mouse pointer.

The new patch still doesn't fix this, perhaps it should be a new bug?

Looks good to me too.  I can corroborate the behaviour Tim is seeing from comment #58 (revisiting comment #38).

My Fedora 15 RPMs are here for ease of testing: https://koji.fedoraproject.org/koji/taskinfo?taskID=3341317

Thanks very much for this patch, previous patches, and all the consideration.

(In reply to comment #58)
> Looks good to me too, thanks Owen!
> 
> revisiting comment 38:
> > However, if you alt-tab to a window from another workspace and on the new
> > workspace the mouse cursor is placed above another window than the one chosen,
> > focus still goes to the one below the mouse pointer.
> 
> The new patch still doesn't fix this, perhaps it should be a new bug?

Would appreciate it, this bug is too long to be manageable.

Comment on attachment 195893 [details] [review]
focus-follows-mouse: ignore events generated when reshaping the stage

looks good. only thing I'd suggest is maybe renaming MetaDisplay->ignore_serials, serial_is_ignored(), and reset_ignores() to clarify that they're only about crossing events as well.

Created attachment 196257 [details] [review]
MetaDisplay: Renamed 'ignored_serials' for clarity

The ignored_serials member of Display refers explicitly to crossing
serials - rename the member and associated functions and constants
for clarity.

Resolving this bug fixed despite residual problems with switching desktops,
since I don't think any of the discussion here about how to fix applies to
that; please file a new bug for residual issues.

Attachment 195893 [details] pushed as 1ab6abc - focus-follows-mouse: ignore events generated when reshaping the stage
Attachment 196257 [details] pushed as e136256 - MetaDisplay: Renamed 'ignored_serials' for clarity