GNOME Bugzilla – Bug 675468
gnome-terminal window should get focus back when mplayer video window is closed
Last modified: 2012-09-26 19:17:26 UTC
When MPlayer or another non-GTK application like Atlas or ProjectX is launched from gnome-terminal, the gnome-terminal window doesn't get focus back once the window opened by the application is closed. STR: 1. Launch mplayer (command line only) from gnome-terminal to play a video, so a MPlayer video window is created. 2. Close the video window either from WM (e.g. hitting Alt+F4) or from MPlayer by pressing 'q'. Actual Results: The gnome-terminal window doesn't have focus (actually, no window on this workspace has focus). Expected Results: The gnome-terminal window where mplayer was launched has focus. This worked fine in GNOME 3.2.2.1 and keeps working fine now with metacity instead of gnome-shell + mutter. rpm -q mutter mutter-3.4.1-2.fc17.x86_64
Probably a regression from the focus stuff that landed in 3.4. It did land in 3.4 and not 3.2.2.1, right?
A local backout of <http://git.gnome.org/browse/mutter/commit/?id=a3bf9b01aa7019798924b618160fcb184e096a3c> fixes this bug for me.
(In reply to comment #1) > [...] It did land in 3.4 and not 3.2.2.1, right? Sorry, didn't know whether the question was directed to me, because I am definitely the wrong person to be asked about GNOME code internals, but the patch mentioned above and related work is indeed in master and in the 3.4 branch only. BTW, backing out this patch fixes one more focus issue: setting a window A to be always on top, moving focus to window B on the same workspace, switching to another workspace and returning to the previous one focuses window A instead of leaving focus at B.
I can confirm this behavior in archlinux/gnome-shell-3.4.1-3, i've noticed the problem first when launching Eclipse projects: once the application quit the previous focused window (the editor window) don't get refocused; i can reproduce the MPlayer/gnome-terminal behavior as well. I run Archlinux and the problem wasn't here in gnome-shell-3.2.2.1-1/mutter-3.2.2-2. Here are the current package version details: Name : mutter Version : 3.4.1-2 Name : gnome-shell Version : 3.4.1-3
On Fedora 17, I have the same behaviour. Only gtk2 and gtk3 applications are behaving correctly with mutter. gtk1.2 do not give focus back to the terminal. I also confirm the bug mentioned in #c3
It might have been a regression that was fixed by: http://git.gnome.org/browse/mutter/commit/?id=e257580b9484762064692b214114442243afa262
Great, it does!
Disclaimer: I was able to test only with the 3.4 branch yet. While the patch in the commit <http://git.gnome.org/browse/mutter/commit/?id=e257580b9484762064692b214114442243afa262> fixes the issue in comment #0, it doesn't address the second regression from <http://git.gnome.org/browse/mutter/commit/?id=a3bf9b01aa7019798924b618160fcb184e096a3c> described in comment #3. Will check again once the Alpha of Fedora 18 is released.
FWIW, I just reported this bug at launchpad at https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1056536 This is probably all moot, but I'll add this information just in case it's not totally fixed. I see the bug when closing Guake, VLC, and smplayer. The second-from-top window never gets focus (the "application indicator" in the menubar normally shows the current application's icon and name, but is blank; the window title is grey, not black). In some cases, total focus is lost (e.g. when nautilus/lyx is the next window), with key-presses not registering. In other cases, some functionality is retained (e.g. when firefox/gedit is the next window, key-presses are still passed). In the latter cases (i.e. firefox/gedit) the bug is just cosmetic. However, in the former cases (i.e. nautilus/lyx), the bug is quite irritating, as you must re-activate the front-most window before continuing.
(In reply to comment #3) > BTW, backing out this patch fixes one more focus issue: setting a window A to > be always on top, moving focus to window B on the same workspace, switching to > another workspace and returning to the previous one focuses window A instead of > leaving focus at B. This is a complicated problem, and that's all I'll say. For now, this is fixed.