Well, yes because it's a shortcut like any other now which means we use X passive grabs which causes FocusOut/In events indeed. I don't know what to say other than fix the clients.

(In reply to comment #1)
> Well, yes because it's a shortcut like any other now which means we use X
> passive grabs which causes FocusOut/In events indeed. I don't know what to say
> other than fix the clients.

Isn't that fixed already in GNOME 3.8?

(In reply to comment #2)
> (In reply to comment #1)
> > Well, yes because it's a shortcut like any other now which means we use X
> > passive grabs which causes FocusOut/In events indeed. I don't know what to say
> > other than fix the clients.
> 
> Isn't that fixed already in GNOME 3.8?

No it can't be "fixed" unfortunately, it's how X grabs work.

Can confirm that. 

And that should be fixed, it's useful for window or widget to do something on focus loss and it's very common to type a message in several languages.

And overall taking a focus from window on every shortcut causes problems. For example, you can't screenshot a drop-down list or pop-up cause they hide on focus loss.

Also (possibly) application shortcuts using keys bound to switch keyboard (i.e. ctrl+shift) are not working because of this. 

For example, if ctrl+shift is set as layout switch shortcut, "copy" shortcut ctrl+shift+c will not work in gnome-terminal. Gnome-terminal not receives keyboard event because when ctrl+shift are pressed, it becomes out of focus.

Maybe report confused with unity-settings-daemon (fork of gnome-settings-daemon in Ubuntu)? Original gnome-settings-daemon does not have code (in media-keys plugin) to switch keyboard layouts:

                  break;
          case BATTERY_KEY:
                  do_battery_action (manager);
                  break;
+         case SWITCH_INPUT_SOURCE_KEY:
+         case SWITCH_INPUT_SOURCE_BACKWARD_KEY:
+                 do_switch_input_source_action (manager, type);
+                 break;
          /* Note, no default so compiler catches missing keys */
          case CUSTOM_KEY:
                  g_assert_not_reached ();

Some clarification:

1. It is unrelated to keyboard layout switching. Any global keyboard shortcuts handled by media-keys plugin of gnome-settings-daemon, such as volume up, volume down, etc., cause focus to switch.

2. As far as I know, vanilla gnome-settings-daemon does not handle switching of keyboard layout, see diff in previous comment. Ubuntu's fork called unity-settings-daemon uses media-keys plugin to switch keyboard and it has code changes to do that.

3. media-keys plugin is not designed to switch keyboard layout, there's a sort of hack in Ubuntu to utilize it for such purpose.

4. Losing focus when pressing volume up/volume down is a minor annoyance. Losing focus when switching keyboard layout is very major annoyance. But AFAIK vanilla gnome does not use 'media-keys' to switch layouts, it uses builtin xkbmap functionality.


Someone who has access to vanilla Gnome, can try following:
 - Bind a key or key combination to volume up/down and something like that
 - Put text caret into input box with visible focus. Good examples are: gnome terminal (cursor will blink), twitter in Firefox (reply box will roll up when losing focus)
 - Press this key multiple times and see focus loses and moves back

Discovered that it is unrelated to gnome-settings-daemon, you can try the following script. It binds '1' key and pressing it causes the same behavior:

#!/usr/bin/python
import dbus
bus = dbus.SessionBus()
o = bus.get_object('org.gnome.Shell', '/org/gnome/Shell')
code = o.GrabAccelerator('1', 0, dbus_interface='org.gnome.Shell')
try:
  raw_input("Grab set to key '1', press Enter to continue and ungrab")
finally:
  print o.UngrabAccelerator(code, dbus_interface='org.gnome.Shell')

(at least in Ubuntu, someone with vanilla Gnome can try it too. Ubuntu uses compiz to implement org/gnome/Shell/GrabAccelerator.)

Still reproducible in 3.16

Ping!

Similar to this bug (and maybe the same) for me on Gentoo Linux. GNOME 3.16.

In nautilus when trying to rename file and switching the keyboard layout it looses focus, changes name to original and I must start from scratch.
In firefox on some websites there are fields critical to focus loss. Some unpredictable things occur.
Geany/Gedit/other text editors - unpredictable behaviour.
Bitwig Studio: I can't use some shortcuts, can't switch keyboard layout in text fields normally, can't type lower/upper letters without using Caps Lock.
Lightworks: various problems with shortcuts related to this.

Debian Jessie, GNOME 3.14. The same as in my previous post about this bug on Gentoo.

(In reply to Maksim Kachur from comment #11)
> Similar to this bug (and maybe the same) for me on Gentoo Linux. GNOME 3.16.
> 
> In nautilus when trying to rename file and switching the keyboard layout it
> looses focus, changes name to original and I must start from scratch.
> In firefox on some websites there are fields critical to focus loss. Some
> unpredictable things occur.
> Geany/Gedit/other text editors - unpredictable behaviour.
> Bitwig Studio: I can't use some shortcuts, can't switch keyboard layout in
> text fields normally, can't type lower/upper letters without using Caps Lock.
> Lightworks: various problems with shortcuts related to this.

As mentioned in comment #3, this can not be fixed in X. This is how X grabs work.

So, the only hope is what Wayland will be by default someday. Because this bug can not be reproduced in GNOME Wayland session.

This bug exists alo in Gnome Wayland (Ubuntu 17.10 with vanilla Gnome).

Reproduce this bug in three simple steps:
1. Start Gedit.
2. Start searching Ctrl+f.
3. Change keyboard layout Win+Space.
BUG: Search widget is gone, focus is nowhere(?).
Step 3. should change keyboard layout, nothing else.

This bug makes it very difficult to use Gnome desktop for non-English speakers :-(

This should get more attention. Really annoying bug lurking there for years. My pain is guake being closed.

This problem is fixed in GNOME Wayland sessions, and unfixable in Xorg sessions at all, so closing.

No, it is not fixed, at least not in GNOME Shell 3.26.1.
I'm running GNOME Wayland sessions and have this problem!

You're right, I tested this with volume keys which had this problem in X11, but not in Wayland.

The problem doesn't lie in gnome-settings-daemon anymore in any case, it's all implemented directly in mutter and gnome-shell now.

Any update on that? I've been encountering the issue on different distros with X11 as well as Wayland for I don't remember how long. I'm happy to provide any  technical information to fix the issue.

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/mutter/-/issues/

Thank you for your understanding and your help.