[regression 45?] '<Super>eacute' keybinding is sometimes sent to windows instead of triggering shortcut action
I have the following keybindings set up through the settings panel and they have been working just fine for close to a decade:
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-1
['<Super>ampersand']
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-2
['<Super>eacute']
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-3
['<Super>quotedbl']
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-4
['<Super>apostrophe']
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-5
['<Super>parenleft']
$ dconf read /org/gnome/desktop/wm/keybindings/switch-to-workspace-6
['<Super>minus']
(FTR these symbols are the first row of keys above the letters on a standard France/French AZERTY PC keyboard; numbers 1-6 need the shift key)
The issue I have is that <Super>eacute
no longer works all the time. If the mouse focus is in a gtk3 or 4 app (gedit, gnome-terminal), they capture the é
and print it out. No such issue in a Qt (vlc), electron (discord) or gtk2 (verbiste) programs.
Also, when in gnome-control-center's "keyboard shortcuts" modal window:
- the keybinding shows as "Super+É" (capital e acute), not sure if "Super+é" should be shown instead
- if I try to re-enter the keybinding, it then shows up as "Super+2" (which would make sense on a US QWERTY keyboard but not on a French AZERTY keyboard)
Since not all programs/libraries are impacted, I originally thought this bug to be linked to #3058 (closed), hence my comment over there, but reverting the patch does nothing to fix this current issue.
It seems to me that gnome-shell 45 is the culprit, whereas 44.4 was ok.