GNOME Bugzilla – Bug 747323
Presenting a window doesn't always give it focus when it should
Last modified: 2015-04-13 09:07:00 UTC
Steps to reproduce: 1. Have some existing window 2. Open Nautilus (or GEdit or Builder) 3. Alt-Tab away from Nautilus 4. Alt-Tab back to Nautilus 5. Without interacting with the Nautilus window, use the app menu to open preferences The newly-mapped preferences window is not focused. Because Nautilus' preferences window is modal, the browser window it is attached to loses input focus and the app menu disappears. In the case of GEdit or Builder, the main window retains input focus. Further attempts to open the already-existing preferences window will raise it but not focus it. Only after interacting with the application's windows in some way (mouse or keyboard input) will the preferences window be focused on the the next attempt to open it. nautilus/gnome-shell/mutter/gtk3 3.16.0 xorg-server 1.17.1
Oh, when trying this with gnome-terminal it's even worse because the focus stealing prevention triggers and the preferences window is not even raised.
Hmm, I'm not immediately reproducing this. Does this always happen when you do the above steps, or only sometimes? Do you have any GNOME Shell extensions installed?
It happens consistently on two different machines running the same software. There are no loaded shell extensions.
A second window is not needed. Another way to reproduce this problem: 1. Open Nautilus (or GEdit or Builder or Terminal) 2. Open the app menu using Super+F10 3. Use keyboard or mouse to open the preferences from the app menu The newly-mapped preferences window is not focused.
Very likely broken here: https://git.gnome.org/browse/gnome-shell/commit/?id=5c5b9cfd96060f8ed9d74d4cb8fea5babc6738dc by the removal of the code to transmit the "desktop-startup-id" platform-data.
Created attachment 301076 [details] [review] Unrevert gtkactionmuxer: Reintroduce the passing of event timestamps Fix an accidental revert of a6a2cea414 - a patch that hacked the cut-and-pasted code from GTK+ to pass timestamps when activating remote actions.
Created attachment 301077 [details] [review] gtkactionmuxer.c: Pass the platform data when activating actions as well The code from a6a2cea414 only passed a timestamp when changing an action state, but the timestamp also to be passed when activating actions.
Review of attachment 301076 [details] [review]: Yeah... sorry about this.
Review of attachment 301077 [details] [review]: Good as well.
Will push to gnome-3-16 as well Attachment 301076 [details] pushed as a0632e3 - Unrevert gtkactionmuxer: Reintroduce the passing of event timestamps Attachment 301077 [details] pushed as 92667e3 - gtkactionmuxer.c: Pass the platform data when activating actions as well
(In reply to Owen Taylor from comment #10) > Will push to gnome-3-16 as well Or, I would have if gnome-3-16 was branched, but is not, so no need.
(In reply to Owen Taylor from comment #11) > > Or, I would have if gnome-3-16 was branched, but is not, so no need. Yeah, the plan is to do that after 3.16.1 next week.
*** Bug 747768 has been marked as a duplicate of this bug. ***