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 675982 - focus follows mouse after closing window
focus follows mouse after closing window
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-05-13 20:01 UTC by Clemens Buchacher
Modified: 2012-07-16 19:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
workspace: Respect the not_this_one parameter passed in (1000 bytes, patch)
2012-07-16 19:18 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review

Description Clemens Buchacher 2012-05-13 20:01:25 UTC
Since an upgrade to version 3.4.1 (from 3.2.x), gnome-shell has started to handle focus differently after a Window is closed. After closing one Window another Window gets focus. With the previous version, it would have been the same Window as if Alt-Tab had been used. But now focus follows mouse, until a Window is clicked.

Such behavior is especially tiresome when starting applications from a terminal, since I have to use Alt-Tab, Alt-Tab every time a child window closes, in order to give focus back to the parent window (i.e., the terminal). For me that's a no-go which forces to use a different window manager for now.
Comment 1 Milan Bouchet-Valat 2012-05-13 20:17:21 UTC
"Focus follows mouse" is a feature with which the window the mouse is over gets the focus without clicking. Is that what you are using?

If not, I don't really understand what you mean by this. "As if Alt+Tab had been used" is not clear (Alt+Tab to what window, for starters?). Could you give us a simple example? If I run gedit from a terminal, and then close the window, I get the terminal, as expected. Do you mean that the terminal should be raised when closing gedit even if another window is over the terminal?
Comment 2 Clemens Buchacher 2012-05-13 22:05:57 UTC
I am not using the "focus follows mouse" feature. I have disabled all extensions to confirm that this is the standard behavior of gnone-shell now.

How to reproduce: Open 3 terminal windows A, B, C in that order. Hover mouse over B while closing C. Confirm that B has focus by typing something. Now repeat the whole procedure but let the mouse hover over A while closing C. Confirm that A has focus by typing something.

Previously, B would have gotten focus no matter where the mouse is, since it had focus last. In the same way, pressing Alt+Tab once only gives the window focus which had focus last before.
Comment 3 Milan Bouchet-Valat 2012-05-14 07:18:37 UTC
(In reply to comment #2)
> I am not using the "focus follows mouse" feature. I have disabled all
> extensions to confirm that this is the standard behavior of gnone-shell now.
> 
> How to reproduce: Open 3 terminal windows A, B, C in that order. Hover mouse
> over B while closing C. Confirm that B has focus by typing something. Now
> repeat the whole procedure but let the mouse hover over A while closing C.
> Confirm that A has focus by typing something.
So this means putting the pointer over B (resp. A) and closing C using Alt+F4?

> Previously, B would have gotten focus no matter where the mouse is, since it
> had focus last. In the same way, pressing Alt+Tab once only gives the window
> focus which had focus last before.
This is what I get here. What window the mouse is over has no effect at all.

Are you using gnome-terminal? Does this happen with other apps too?
Comment 4 Clemens Buchacher 2012-05-14 21:15:04 UTC
I was using Ctrl+D to close the terminals. But Alt+F4 should work too. I tried it with both gnome-terminal, xterm and nautilus. So it does not really matter what app you use.

So, is this not reproducible? Is something messed up in my configuration?
Comment 5 Clemens Buchacher 2012-05-20 16:39:53 UTC
Note that the mouse has to be in the window content area, not in the title bar or in the window frame. Otherwise no window gets focus.
Comment 6 Clemens Buchacher 2012-07-01 01:29:04 UTC
I can reproduce this on a different machine which I setup with Arch Linux from scratch. Without any configuration changes.
Comment 7 arnoques 2012-07-02 23:19:36 UTC
I also get a very similar behavior, and it started when I upgraded to gnome 3.4. I'm using Debian testing with gnome-shell 3.4.1-8.

In my box I can't reproduce it with Clemen's instructions, though. To make it happen I do
1) open any application (I tried nautilus, geany and gedit). Let's say it's gedit
2) open gnome-terminal
3) from the terminal open certain applications(*) that create new windows
4) place the mouse over gedit, which is under both the terminal and the new window.
5) close the new window
6) at this point, no window has focus (at least none of them shows it in their decorations) and if I type anything, gedit receives the keypresses, instead of the terminal.

(*) Not all applications give me this behavior. This ones do: mplayer, feh, octave (when I make any plot), imagej. This ones don't: gnome-sudoku, gnome-sudoku, geeqie.

Is there anything I can do to help you debug this?
Thanks,
  Arnoques
Comment 8 Clemens Buchacher 2012-07-07 15:27:05 UTC
I tried to bisect the problem. I could go back to version 3.3.92, which still has the bug. Then I got stuck due to external dependencies which made it impossible to compile older versions of gnome-shell. Does anyone know a surefire way to install older versions of gnome-shell such as 3.2.x, 3.3.x?

I guess I could install ubuntu oneiric which comes with 3.2.0. But we already know that that version has the bug.

Other than that, any clues which part of the source code I should be looking at?
Comment 9 Clemens Buchacher 2012-07-14 14:15:48 UTC
Found it: Reverting a3bf9b01 (workspace: Don't try to use per-workspace MRU lists as a hint for focusing) in https://bugs.archlinux.org/task/30023?getfile=8843 on top of version 3.4.1 fixes this issue.

The commit references https://bugzilla.gnome.org/show_bug.cgi?id=620744 .
Comment 10 Clemens Buchacher 2012-07-14 17:32:03 UTC
Re-assigned to mutter.

Erm, the previous message should have said: Reverting a3bf9b01 (workspace: Don't try to use per-workspace MRU lists as a hint for focusing) in mutter on top of version 3.4.1 fixes this issue.
Comment 11 Jasper St. Pierre (not reading bugmail) 2012-07-14 18:56:52 UTC
What happens if you apply https://bugzilla.gnome.org/attachment.cgi?id=218768 ?
Comment 12 Clemens Buchacher 2012-07-14 21:16:33 UTC
That fixes it too.
Comment 13 Jasper St. Pierre (not reading bugmail) 2012-07-14 21:19:53 UTC
Yep. Thought so. drago01, review? Patch is in:

https://bugzilla.gnome.org/show_bug.cgi?id=647706
Comment 14 Jasper St. Pierre (not reading bugmail) 2012-07-16 19:18:53 UTC
Created attachment 218943 [details] [review]
workspace: Respect the not_this_one parameter passed in

In the case of focus-follows-mouse, we need to ensure that we
do not select a certain window after closing another one.
Comment 15 drago01 2012-07-16 19:21:00 UTC
Review of attachment 218943 [details] [review]:

Looks good.
Comment 16 Jasper St. Pierre (not reading bugmail) 2012-07-16 19:22:15 UTC
Attachment 218943 [details] pushed as e257580 - workspace: Respect the not_this_one parameter passed in