*shrug* Works for me in 3.20.1 and master.

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.

(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

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.

It's worth mentioning that the same problem affects gnome-software too, so it's probably not gnome-control-center's problem.

So could you move this to another product so that it can be triaged? Maybe the problem is in GTK or somewhere else?

Wow, ti's

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

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.

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.

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

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

Note that patch is not sufficient because GDK_MODIFIER_MASK includes GDK_META_MASK, I wound up pushing something more complicated. :(

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.

Can somebody please verify that it doesn't break under Xorg?

For the record, the change is due to commit bc6d2d6 in gtk+ to address bug 748904

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

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

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.

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

Review of attachment 343323 [details] [review]:

Yeap, that's what I had in mind :)

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.

Review of attachment 343323 [details] [review]:

So then should I revert https://git.gnome.org/browse/epiphany/commit/?h=gnome-3-22&id=5124ed62930a5d0ac52f9aefcd7b208d0e18354b...?

Review of attachment 343325 [details] [review]:

yep

Review of attachment 343323 [details] [review]:

ok then

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