GNOME Bugzilla – Bug 703265
keyboard focus not moved correctly
Last modified: 2013-10-08 17:06:26 UTC
Many times recently I've noticed that when I alt tab to another app the new window comes to the foreground visually but doesn't get keyboard focus. All typing goes to the previously used window. This is not only confusing as all get out but a pretty serious security issue.
Observed on gnome-shell-3.8.3-2.fc19.x86_64.
Moving to Mutter, since shell has minimal involvement here, and there were changes in the Mutter code prior to 3.8. Do the window decorations and the focused state change for the old window? For the new window? If anybody can provide reproduction instructions, that would be appreciated (I've never seen this on my system, so it's probably specific to *something*)
I'm using maximized windows so can't answer the first and second question. But I think that the app menu definitely changed. I was in google docs writing a Document and I got a notification that my name was mentioned on irc. I can't recall if I clicked the notification or I used alt-tab. Likely one or the other. But when it switched to xchat visually the keyboard focus was still in gdocs/Firefox and I typed into my document.
Can you reproduce this if intentionally with non-maximized windows? "visually the keyboard focus was still in gdocs/Firefox" What does that mean in detail?
There are known bugs about XChat and notifications and keyboard focus, but every time I've tried to debug it, it went away.
Created attachment 256666 [details] [review] notificationDaemon: Supply a bigger timestamp when activating the window When the user clicks on the notification, we first try to focus the last window that the user was looking at. Afterwards, we try to focus the window that the user wanted to raise. There's a race here: when we focus each window, we send them both WM_TAKE_FOCUS events with the same exact timestamp, which means that the winner is whoever processed their message and sent it off to the server last. This is worsened by a recent mutter bug that gets tripped up in situations like this, leading it to stop tracking the FocusIn for the window afterwards, making it look like no window is focused, but the last app actually does have focus. There's no easy way to prevent the re-focusing behavior from happening, so as a hack, make the window that the user actually wanted to raise with the notification "win" the race by giving it a bigger timestamp.
Created attachment 256671 [details] [review] notificationDaemon: Focus the new window before destroying the notification Destroying the notification will make the key focus be reset to NULL, which means that gnome-shell will try to focus the MRU window, thinking the user is done interacting and wants to go back to whatever they were doing. Unfortunately, since we focus two windows at the same time, they will have the same timestamp, meaning that the window that actually gets focused will be a race as to whoever responds to their WM_TAKE_FOCUS event last. If we explicitly set the focus beforehand, then gnome-shell will believe it got key focus taken away from it, and won't try to focus the MRU when the key focus drops to NULL. --- A simpler approach that prevents focusing the other window.
Review of attachment 256671 [details] [review]: Looks good to me
Attachment 256671 [details] pushed as 55edfd2 - notificationDaemon: Focus the new window before destroying the notification