← Back to team overview

compiz team mailing list archive

[Bug 1244090] Re: Pressing any global keyboard shortcut causes temporary loss of focus

 

Launchpad has imported 19 comments from the remote bug at
https://bugzilla.gnome.org/show_bug.cgi?id=700316.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2013-05-14T16:24:45+00:00 Federico Mena Quintero wrote:

(I'm not sure if gnome-settings-daemon is the right product for this
bug, but anyway.)

I have things so that pressing ShiftL+ShiftR together will change my
keyboard layout.

This works fine.  However, when I press that key combination, the
current window appears to lose focus and regain it instantly.  This is a
problem with buggy toolkits (cough) that do things like committing or
canceling text entries when they lose/gain focus.  For example,
GtkTreeView will cancel editing, and Firefox will do funny things
depending on which web page has entry widgets in it.

This didn't seem to happen a few Gnome versions ago (maybe it was caused
by the switch to ibus?).

Here is the xev log for what it's worth.  After the initial ShiftL
KeyPress, there is a FocusOut/FocusIn/KeymapNotify.

KeyPress event, serial 44, synthetic NO, window 0x4800001,
    root 0xc1, subw 0x0, time 257173342, (412,453), root:(413,530),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 44, synthetic NO, window 0x4800001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 44, synthetic NO, window 0x4800001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 44, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   4   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

MappingNotify event, serial 44, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 44, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 44, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 44, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 44, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 44, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 44, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 44, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

KeyRelease event, serial 44, synthetic NO, window 0x4800001,
    root 0xc1, subw 0x0, time 257173533, (412,453), root:(413,530),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/0

------------------------------------------------------------------------
On 2013-05-14T16:28:38+00:00 Rui Matos wrote:

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.

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/1

------------------------------------------------------------------------
On 2013-05-14T16:29:56+00:00 Bugzilla-x wrote:

(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?

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/2

------------------------------------------------------------------------
On 2013-05-14T16:32:47+00:00 Rui Matos wrote:

(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.

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/3

------------------------------------------------------------------------
On 2013-10-26T05:48:07+00:00 Suor wrote:

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.

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/7

------------------------------------------------------------------------
On 2013-10-26T05:58:25+00:00 Suor wrote:

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.

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/8

------------------------------------------------------------------------
On 2013-11-11T07:08:23+00:00 kolen wrote:

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.

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/11

------------------------------------------------------------------------
On 2014-04-25T10:37:09+00:00 kolen wrote:

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 ();

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/18

------------------------------------------------------------------------
On 2014-04-28T12:12:46+00:00 kolen wrote:

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

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/25

------------------------------------------------------------------------
On 2014-04-29T10:46:55+00:00 kolen wrote:

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.)

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/27

------------------------------------------------------------------------
On 2015-09-21T19:24:22+00:00 Serge Gavrilov wrote:

Still reproducible in 3.16

Ping!

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/63

------------------------------------------------------------------------
On 2016-01-23T15:13:46+00:00 Maksim Kachur wrote:

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.

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/68

------------------------------------------------------------------------
On 2016-01-23T16:31:30+00:00 Maksim Kachur wrote:

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

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/69

------------------------------------------------------------------------
On 2016-01-23T19:07:27+00:00 Nexfwall wrote:

(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.

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/70

------------------------------------------------------------------------
On 2017-10-25T10:42:17+00:00 Martin Měřinský wrote:

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 :-(

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/81

------------------------------------------------------------------------
On 2017-10-26T03:47:41+00:00 Suor wrote:

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

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/82

------------------------------------------------------------------------
On 2017-10-31T10:47:19+00:00 Bugzilla-x wrote:

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

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/83

------------------------------------------------------------------------
On 2017-10-31T10:51:21+00:00 Martin Měřinský wrote:

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

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/84

------------------------------------------------------------------------
On 2017-10-31T11:02:02+00:00 Bugzilla-x wrote:

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.

Reply at: https://bugs.launchpad.net/mutter/+bug/1244090/comments/85


** Changed in: mutter
       Status: Unknown => Confirmed

** Changed in: mutter
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1244090

Title:
  Pressing any global keyboard shortcut causes temporary loss of focus

To manage notifications about this bug go to:
https://bugs.launchpad.net/mutter/+bug/1244090/+subscriptions