After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 611089 - Accelerator for ctrl+space triggered when only space pressed in fr-oss layout
Accelerator for ctrl+space triggered when only space pressed in fr-oss layout
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 659129 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-02-25 15:47 UTC by Noam Yorav-Raphael
Modified: 2014-08-20 19:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test with gtk_binding_entry_add_signal(), works well. (1.84 KB, text/plain)
2011-09-16 21:04 UTC, Sébastien Wilmet
  Details
Test with GtkAccelGroup: bug (1006 bytes, text/plain)
2011-09-16 21:06 UTC, Sébastien Wilmet
  Details
GtkKeyHash: fix misuse of consumed modifiers (1.21 KB, patch)
2012-07-28 16:15 UTC, Sébastien Wilmet
none Details | Review

Description Noam Yorav-Raphael 2010-02-25 15:47:59 UTC
Hello,

This report follows https://bugs.launchpad.net/dreampie/+bug/525502 .

In the fr-oss keyboard layout, an event which is supposed to be triggered by pressing ctrl+space is triggered by every press on space.

To reproduce:

Write this into a file (accel_bug.py, for example):
==================
import gtk
w = gtk.Window()
ag = gtk.AccelGroup()
def cb(*args):
    print 'hi'
ag.connect_group(ord(' '), gtk.gdk.CONTROL_MASK, 0, cb)
w.add_accel_group(ag)
w.show_all()
gtk.main()
==================

If I just run python accel_bug.py, a window appears and whenever you press ctrl+space, "hi" is printed to the terminal.

If before that I switch to fr-oss keyboard layout, by running
setxkbmap fr oss
then whenever I press the space key "hi" is printed, even without pressing ctrl.

I run ubuntu karmic 9.10 on i386.

Thanks,
Noam
Comment 1 Sébastien Wilmet 2011-09-16 15:31:21 UTC
*** Bug 659129 has been marked as a duplicate of this bug. ***
Comment 2 Tanguy Ortolo 2011-09-16 15:55:39 UTC
This bug is linked to one specific feature of the keymap fr(oss): it inherits from nbsp(level4nl) which defines the space key as LOCAL_EIGHT_LEVEL, bearing the
symbols space, no-break space in combination with Shift + AltGr and narrow
no-break space in combination with Shift + Ctrl_Right.

This bug does not reproduce when you load the keymap fr-oss using an option that loads another rule for the space key, for instance nbsp:level3n:
    $ setxkbmap -layout fr -variant oss -option nbsp:level3n

I guess this bug would be reproducible with any keymap as long as the option nbsp:level4nl is used.
Comment 3 Tanguy Ortolo 2011-09-16 15:56:16 UTC
PS: I use Debian testing on amd64.
Comment 4 Sébastien Wilmet 2011-09-16 21:03:05 UTC
If the Ctrl+space shortcut is added with gtk_binding_entry_add_signal(), there is no problem.

The bug occurs only with a GtkAccelGroup.

That's why the Ctrl+space shortcut for showing the completion in GtkSourceView works well, because it uses gtk_binding.  But if we add the same shortcut in a menu (with a GtkActionEntry), then the bug occurs, because a GtkAccelGroup is used.

I attach two C programs. It's fairly easy to reproduce the bug, we just have to change the keyboard layout to "fr oss":

> $ setxkbmap fr oss
Comment 5 Sébastien Wilmet 2011-09-16 21:04:26 UTC
Created attachment 196777 [details]
Test with gtk_binding_entry_add_signal(), works well.
Comment 6 Sébastien Wilmet 2011-09-16 21:06:16 UTC
Created attachment 196779 [details]
Test with GtkAccelGroup: bug

It's the same as the Python code from the first comment, but in C language.
Comment 7 Sébastien Wilmet 2012-07-28 15:49:39 UTC
The problem comes from the _gtk_key_hash_lookup() function.

I think there is a misuse of the consumed modifiers returned by gdk_keymap_translate_keyboard_state(). Here is the relevant code:

> if (gdk_keymap_map_virtual_modifiers (key_hash->keymap, &modifiers) &&
>     ((modifiers & ~consumed_modifiers & mask & ~vmods) == (state & ~consumed_modifiers & mask & ~vmods) ||
>      (modifiers & ~consumed_modifiers & mask & ~xmods) == (state & ~consumed_modifiers & mask & ~xmods)))

In the case of a Ctrl+Space accelerator, and a simple space is pressed:
- 'modifiers' is GDK_CONTROL_MASK (the modifiers of the accelerator).
- 'state' is 0 (the modifiers of the GdkEventKey).
- 'consumed_modifiers' has several modifiers activated, like GDK_SHIFT_MASK and GDK_LOCK_MASK. But here is the problem, with the fr oss keyboard layout, GDK_CONTROL_MASK is also present in consumed_modifiers, while it is not present with other keyboard layouts that most people use.

With GDK_CONTROL_MASK present in consumed_modifiers, the if condition is true and the accelerator is activated.

As described in the note of the documentation about gdk_keymap_translate_keyboard_state(), it seems that

> modifiers & ~consumed_modifiers

is not correct. It should be:

> if (gdk_keymap_map_virtual_modifiers (key_hash->keymap, &modifiers) &&
>     ((modifiers & mask & ~vmods) == (state & ~consumed_modifiers & mask & ~vmods) ||
>      (modifiers & mask & ~xmods) == (state & ~consumed_modifiers & mask & ~xmods)))

Now the simple space doesn't trigger the ctrl+space accelerator. Nice!

But there is another problem, now when we press ctrl+space, the accelerator is not triggered (with the fr oss layout). Indeed, the 'state' now contains GDK_CONTROL_MASK, but it is removed by the consumed modifiers.

Maybe the bug comes from the gdk_keymap_translate_keyboard_state() function: does it return the correct consumed modifiers?

In the case of Ctrl+space in fr oss, the keyval is the "normal" space character. So is it normal that GDK_CONTROL_MASK is present in consumed_modifiers?

Also, it seems strange to me that the consumed_modifiers contains modifiers that are not present in the 'state'. According to the documentation:

> An older interpretation consumed_modifiers was that it contained all
> modifiers that might affect the translation of the key

I'm maybe wrong, but it seems that the old interpretation is still the case.

I use the X11 backend, so gdk_x11_keymap_translate_keyboard_state() is called.
Comment 8 Sébastien Wilmet 2012-07-28 16:15:38 UTC
Created attachment 219794 [details] [review]
GtkKeyHash: fix misuse of consumed modifiers

Use the new interpretation of the consumed modifiers returned by
gdk_keymap_translate_keyboard_state().
Comment 9 Sébastien Wilmet 2014-08-20 19:06:52 UTC
I cannot reproduce this bug anymore with gtk+ 3.13.