Super-period broken by F39 upgrade

Hello! I have custom bindings for changing workspaces:

✸ dconf dump /org/gnome/desktop/wm/keybindings/ | grep -Ei 'super.(comma|period)'
move-to-workspace-left=['<Shift><Super>comma']
move-to-workspace-right=['<Shift><Super>period']
switch-to-workspace-left=['<Super>comma']
switch-to-workspace-right=['<Super>period']

These worked for me until upgrading to F39. Now they work some of the time, but other times they seem to be captured by the terminal emulator. Somewhat suprisingly, it doesn’t matter what terminal I use—gnome terminal, console, kitty, alacritty—they all experience the problem.

Once triggered, all the keys I press appear as underlined in the terminal, until I press enter. I would get a screenshot for you, but that’s difficult because even the PrintScreen key is captured. Here is a photo, it’s the best I can do:

It seems like I must be hitting on something that intends to be a feature, but I’m not sure what it is, or if it can be reconfigured to avoid interfering with my preferred shortcuts. Any suggestions?

I have the same problem with Shift+Super+3 to move the current window to the third workspace - in F39 it no longer works reliably for gnome-terminal which sometimes intercepts it and inserts £ instead.

It doesn’t happen for other Shift+Super+<digit> combinations though.

1 Like

Keystrokes often are captured by the window that has focus.
Click on the desktop so a window does not have focus then those keys should work consistently.

Although shifting workspaces is defined by default in gnome as move window one workspace right as super+shift+pageup and move window one workspace left as super+shift+pagedown.

Thanks, Tom. Nice to know I’m not the only one seeing the change in F39.

FWIW I made a temporary fresh user and verified it happens there, too, so it’s not an extension causing problems.

It seems like GNOME 45 may have changed something in how keys are intercepted by apps. Previously, the shortcut assignment would override, but now the app gets first crack?

The fact that it happens in multiple terminal emulators with wildly different implementations suggests this is still somehow tied to GNOME.

Found it! Changing this from default to ['<Super>semicolon'] frees up this key for me:

Sounds like a different problem to me then - you had two meanings bound to that key one of which started processing an emoji sequence which was triggering your weird input behaviour.

1 Like

Right, and unfortunately I haven’t been able to repro your problem with <Super><Shift>3

Also, I just got lucky stumbling across this. In my limited attempts, I couldn’t find any way in dconf or dconf-editor to search through the default values when not overridden. If there’s a way to do that, it could be useful (and might help track down your issue, too)

FWIW, there is a UI for this: ibus-setup, but it’s hidden from the menus.

1 Like

This sounded very familiar to me, and I found: Ctrl + Shift + $ shortcut not working on Wayland (GNOME 40) (#1528) · Issues · GNOME / Settings · GitLab, which was fixed by always setting the binding to include the number rather than ‘dollar’.

I can reproduce your issue here if I use a UK layout. It affects all GTK apps when using the Wayland backend. It’s probably the same issue as: