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 770112 - The documented <alt>left shortcut doesn’t work on Wayland
The documented <alt>left shortcut doesn’t work on Wayland
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Wayland
Depends on:
Blocks:
 
 
Reported: 2016-08-18 20:31 UTC by Arnaud B.
Modified: 2017-01-17 17:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
shell: Fix Alt navigation shortcuts on Wayland (3.15 KB, patch)
2017-01-11 12:15 UTC, Bastien Nocera
none Details | Review
gdk/wayland: Don't add GDK_META_MASK to gdk mod masks if MOD1 is set (1.43 KB, patch)
2017-01-11 17:58 UTC, Rui Matos
committed Details | Review
gdk/wayland: Always get the seat's key modifiers from the GdkKeymap (1.37 KB, patch)
2017-01-11 18:23 UTC, Rui Matos
committed Details | Review

Description Arnaud B. 2016-08-18 20:31:30 UTC
There’s a documented (in the Shortcuts window) “Alt + ←” shortcut to go from a panel to the main view, but it doesn’t work.
Comment 1 Ernestas Kulik 2016-08-20 07:56:22 UTC
*shrug* Works for me in 3.20.1 and master.
Comment 2 Arnaud B. 2016-08-20 09:02:06 UTC
So, to be complete :
* Fedora 25+Rawhide ;
* Wayland session ;
* gnome-control-center 3.20.1, gtk+ 3.21.4, glib 2.49.4 ;
* default locale french, but launching with LANG=C behaves the same.

Is your session a Wayland one ? I’ll try to compile master when possible.
Comment 3 Ernestas Kulik 2016-08-20 09:06:35 UTC
(In reply to Arnaud B. from comment #2)
> Is your session a Wayland one ? I’ll try to compile master when possible.

Ah, that could mean something.

Arch Linux,
X session,
g-c-c 3.20.1; GTK+ 3.20.9; GLib 2.48.1,
en_US locale
Comment 4 Nate Graham 2016-11-24 20:10:22 UTC
This is definitely broken only in Wayland.

I'm using Fedora 25 + GNOME 3.22 + English locale. Under X, the shortcut works. With Wayland, it doesn't.
Comment 5 Nate Graham 2016-11-26 00:21:35 UTC
It's worth mentioning that the same problem affects gnome-software too, so it's probably not gnome-control-center's problem.
Comment 6 Nate Graham 2016-12-14 02:02:24 UTC
So could you move this to another product so that it can be triaged? Maybe the problem is in GTK or somewhere else?
Comment 7 Michael Catanzaro 2017-01-07 19:07:38 UTC
Wow, ti's
Comment 8 Michael Catanzaro 2017-01-07 19:11:38 UTC
Wow, I typed two words, misspelled half of them, forgot I did so, and posted them as a comment. I was planning to say: "wow, it's the first issue from bug #772437".
Comment 9 Olivier Fourdan 2017-01-10 15:31:25 UTC
The issue is affecting GtkNotebook apparently (as used by control-center), it's also reproducible using the GtkNotebook in gtk3-widget-factory on Page 3.
Comment 10 Olivier Fourdan 2017-01-10 17:25:24 UTC
Sorry, this particular shortcut is handled in shell/cc-window.c in the case of g-c-c and the action is not triggered because of the state, it contains additional bits.

e.g.:

g-c-c tests  "state == GDK_MOD1_MASK" in window_key_press_event() but in gdb we can see the action is not triggered because state == 0x10000008 whereas GDK_MOD1_MASK is 0x8, so they don't match.

Changing the test to "state & GDK_MOD1_MASK" in window_key_press_event() triggers the action though.
Comment 11 Michael Catanzaro 2017-01-10 18:53:08 UTC
Ah, then that's the same problem as was hit by Epiphany... you might want to look to see how I handled it there (bug #772437).
Comment 12 Olivier Fourdan 2017-01-10 19:37:38 UTC
Yeap, same as attachment 340568 [details] [review] indeed, but I wanted to get a bit further and try to understand why we get the GDK_META_MASK (1 << 28 if I am not mistaken) as well but on Wayland only...
Comment 13 Michael Catanzaro 2017-01-10 20:46:52 UTC
Note that patch is not sufficient because GDK_MODIFIER_MASK includes GDK_META_MASK, I wound up pushing something more complicated. :(
Comment 14 Bastien Nocera 2017-01-11 12:15:25 UTC
Created attachment 343297 [details] [review]
shell: Fix Alt navigation shortcuts on Wayland

The default mod mask is different in Xorg and in Wayland. In Wayland, it
contains GDK_META_MASK (which is the virtual modifier equivalent to Mod1
aka Alt) whereas it doesn't contain it under Xorg.

Therefore, make sure to remove GDK_MOD1_MASK and and use the
GDK_META_MASK to check for the "Alt" key or equivalent.
Comment 15 Bastien Nocera 2017-01-11 12:15:53 UTC
Can somebody please verify that it doesn't break under Xorg?
Comment 16 Olivier Fourdan 2017-01-11 15:36:28 UTC
For the record, the change is due to commit bc6d2d6 in gtk+ to address bug 748904
Comment 17 Rui Matos 2017-01-11 17:32:15 UTC
(In reply to Olivier Fourdan from comment #16)
> For the record, the change is due to commit bc6d2d6 in gtk+ to address bug
> 748904

Right, I think that patch shouldn't have added the GDK_META_MASK bit for the same reason that we have this comment in gdkkeys-x11.c:

  /*  This loop used to start at 3, which included MOD1 in the
   *  virtual mapping. However, all of GTK+ treats MOD1 as a
   *  synonym for Alt, and does not expect it to be mapped around,
   *  therefore it's more sane to simply treat MOD1 like SHIFT and
   *  CONTROL, which are not mappable either.
   */

So, we need to fix this in gtk+ to keep event state compatible with the X behavior and avoid needless app breakage.
Comment 18 Matthias Clasen 2017-01-11 17:45:53 UTC
I don't think thats true ? We already ignore mappings _to_ Mod1 in the wayland backend when adding vmods:

      real &= 0xf0; /* ignore mapping to Lock, Shift, Control, Mod1 */

And we do treat META like the other vmods in the X11 backend as well.

I think this needs some more research
Comment 19 Rui Matos 2017-01-11 17:58:09 UTC
Created attachment 343323 [details] [review]
gdk/wayland: Don't add GDK_META_MASK to gdk mod masks if MOD1 is set

Gtk+ treats MOD1 as a synonym for Alt, and does not expect it to be
mapped around, so we should avoid adding GDK_META_MASK if MOD1 is
already included to avoid confusing gtk+ and applications that rely on
that behavior.
Comment 20 Rui Matos 2017-01-11 18:01:43 UTC
(In reply to Matthias Clasen from comment #18)
> I don't think thats true ? We already ignore mappings _to_ Mod1 in the
> wayland backend when adding vmods:
> 
>       real &= 0xf0; /* ignore mapping to Lock, Shift, Control, Mod1 */
> 
> And we do treat META like the other vmods in the X11 backend as well.

We do, but since I changed mutter to send virtual modifiers, the xkb state object we have on the wayland backend has both real and virtual modifiers and that's where we look for modifiers when filling in the event's state. See gdkdevice-wayland.c:deliver_key_event()
Comment 21 Olivier Fourdan 2017-01-11 18:23:11 UTC
Review of attachment 343323 [details] [review]:

Yeap, that's what I had in mind :)
Comment 22 Rui Matos 2017-01-11 18:23:19 UTC
Created attachment 343325 [details] [review]
gdk/wayland: Always get the seat's key modifiers from the GdkKeymap

Elsewhere we already go through the keymap to get modifiers so we
should do the same here. In fact, this was relying on xkb modifier
mask values being bitwise compatible with GdkModifierType which isn't
necessarily true.
--

This is a drive-by cleanup. Not related to this particular bug but it
means that we could still include GDK_META_MASK and GDK_MOD1_MASK in
other (non-key) input events.
Comment 24 Matthias Clasen 2017-01-12 14:46:21 UTC
Review of attachment 343325 [details] [review]:

yep
Comment 25 Matthias Clasen 2017-01-12 14:49:03 UTC
Review of attachment 343323 [details] [review]:

ok then
Comment 26 Bastien Nocera 2017-01-17 17:22:31 UTC
Attachment 343323 [details] pushed as 33c1020 - gdk/wayland: Don't add GDK_META_MASK to gdk mod masks if MOD1 is set
Attachment 343325 [details] pushed as 4f80d23 - gdk/wayland: Always get the seat's key modifiers from the GdkKeymap