1770296 – GNOME on F31: Switching Workspace results in "Ctrl+Alt+Up" key press getting sent to active application

Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1770296 - GNOME on F31: Switching Workspace results in "Ctrl+Alt+Up" key press getting sent to active application

Summary: GNOME on F31: Switching Workspace results in "Ctrl+Alt+Up" key press getting ...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Fedora
Classification:	Fedora
Component:	gnome-shell
Sub Component:
Version:	31
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	low
Target Milestone:	---
Assignee:	Florian Müllner
QA Contact:	Fedora Extras Quality Assurance
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2019-11-08 16:32 UTC by Alex Scheel
Modified:	2020-06-01 13:49 UTC (History)
CC List:	16 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2020-05-05 07:53:22 UTC
Type:	Bug
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
GNOME Gitlab	GNOME gnome-shell issues 1738	0	None	None	None	2019-11-12 13:52:19 UTC
GNOME Gitlab	GNOME mutter issues 812	0	None	None	None	2019-11-12 13:52:19 UTC

Description Alex Scheel 2019-11-08 16:32:02 UTC

Description of problem:

I love workspaces and use the dynamic expanding workspace feature a lot. Typically workspace 0 is various terminals (including IRC), workspace 1 are main browsers, and then workspaces 2 and above a combinations of terminal+browser per project. I switch between these workspaces a lot with ctrl+alt+{up,down} and move applications between them with ctrl+alt+shift+{up,down}.

Since upgrading to Fedora 31 on two machines, I've noticed that frequently an "ctrl+shift+up" key press event gets sent to the focused application on the _destination_ workspace. This most frequently occurs when going up the workspace stack; much more rarely when I'm going down the workspace stack. This manifests itself as an "A" in the terminals (or, when Telegram is open, it triggers an edit on my last-sent message). When going down, I rarely get a "B" in the stack.

I like to think that I'm not abnormally quick at pressing it though -- it happens more frequently on "shorter" ctrl+alt+up than it does on "longer" ctrl+alt+up presses.

When doing this on the top workspace (where going up can't take you anywhere), I notice that the "A" gets sent to the active application _before_ the animation for the workspace switcher begins (where it overlays the workspace stack).

Another symptom of this problem is that, while it is easy to bring a window _down_ in the workspace stack by one workspace, sometimes bringing a window _up_ results in it going up TWO workspaces, even though a single ctrl+alt+shift+up is pressed. I'm guessing this too is related to timing.

Has behavior changed here? Is there a configuration value I can change?

I don't have rawhide to test on. Should I file this upstream?

Version-Release number of selected component (if applicable):

gnome-shell-3.34.1-2.fc31.x86_64

How reproducible:

Very on F31.

Steps to Reproduce:
1. Open GNOME3 in Fedora 31. Launch and focus a single gnome-terminal window.
2. Press and release ctrl+alt+up quickly.

Actual results:

Notice that "A" now appears on the command prompt. i.e., a keypress for that shortcut is registered.

Expected results:

No "A" appears on the prompt, implying that no kepress for that shortcut is registered by the focused application.

Comment 1 Alex Scheel 2019-11-08 16:36:03 UTC

Apologies; title is correct, body isn't: 

...I've noticed that frequently an "ctrl+shift+up" key press event gets...

should be:

...I've noticed that frequently an "ctrl+ALT+up" key press event gets...

Comment 2 Daniel Berrangé 2019-11-11 17:11:53 UTC

I've seen the same behaviour in GNOME shell since Fedora 31, a regression from F30 behaviour AFAICT. It does seem to be pretty non-deterministic, but frequent enough that its triggering many times a day, and led to me accidentally resending chat instant messages several times.

Comment 3 Peter Jones 2019-11-12 15:23:21 UTC

I'm not 100% certain, but I think this happens more frequently if both workspaces have a terminal that will be the active window before and after switching - though obviously it could be happening all the time, but a terminal being in focus is the only place I'd see the symptom.   Which terminal app is running makes a huge difference; anything operating in raw mode will be different from cooked mode, vim will behave differently in insert mode vs not, etc.

If you run screen you'll see that they're escape codes, so to get a better look I did:

Terminal 1                                    Terminal 2
$ tty
/dev/pts/2
$ stty raw ; hexdump -C
*switch workspaces a bunch of times*
                                              $ stty -F /dev/pts/2 -raw
*enter*
^D
                       ^[[1;7B^
00000000  1b 5b 31 3b 37 42 0a                              |.[1;7B.|
00000009
$ 

So it appears to be ^[[1;7A (ESC [ Pn ; Pn A) and ^[[1;7B (ESC [ Pn ; Pn B), and at least for me the parameters do always seem to be 1 and 7.  A bit odd, as 2-parameter A and B functions don't seem to be in terminfo/termcap at all, but possibly the chosen code is intended as an extension that's thematically similar to CUU (ESC [ Pn A) and CUD (ESC [ Pn B).

Comment 4 Peter Jones 2019-11-12 15:28:57 UTC

After some more experimenting, it appears the order of hitting the keys matters, and that may be what's making this appear non-deterministic.   If I hit Alt+Ctrl+{Dp,Down}, it triggers pretty consistently, if I hit Ctrl+Alt+{Up,Down}, it does not.

Comment 5 Dave Allan 2020-01-05 02:49:43 UTC

I'm seeing this behavior with any workspace switching keyboard shortcut, and the keystrokes are received by any active window on the destination workspace, not just shells.  I've seen Firefox receive Ctrl-F4 and close, for example.  I think it's 100% reproducible.  For example, I defined Ctrl-F3 to switch to workspace 3.  If I have a gnome-terminal window with emacs running in it on workspace 3, switch to some other workspace, and then hit Ctrl-F3, gnome switches to workspace 3 and emacs reports "<C-f3> is undefined"  Other workspaces behave similarly with their keyboard shortcuts reported as undefined by emacs.

Comment 6 Dave Allan 2020-01-05 03:06:46 UTC

Interesting, I am indeed seeing this 100% of the time, but it's a little harder to reproduce than I thought: it has to be the first keystroke that switches to the workspace.  Specifically, I have Ctrl-F1 through Ctrl-F12 defined for 12 static workspaces.  If I open a terminal on workspace 3, and I hit Ctrl-F1, then Ctrl-F3 without releasing Ctrl, then gnome switches to workspace 3, and I do not see Ctrl-F3 received by terminal.  If I hit Ctrl-F1, release Ctrl, then hit Ctrl-F3, I see Ctrl-F3 received by the terminal (or whatever window has focus on the target workspace).  I can also reproduce the exact behavior reported in comment 4 regarding the order of pressing Ctrl and Alt.

Comment 7 renan.ifce 2020-01-07 14:45:42 UTC

I can reproduce the behavior reported by Peter Jones about the order to press Ctrl and Alt in the gnome shell in wayland. In gnome shell with xorg I cannot reproduce the same behavior. Maybe the problem ocurrs only with the wayland.

Comment 8 Dave Allan 2020-01-10 17:50:41 UTC

FWIW, I'm only seeing it on the left control key on my Kinesis Advantage keyboard.  The right control key works properly.

Comment 9 Thomas Petazzoni 2020-03-30 07:55:23 UTC

I am still affected by this bug, on an updated Fedora system. It is really annoying on a daily basis. Anything can be done to get it fixed?

Comment 10 Abrahm Scully 2020-03-30 10:44:40 UTC

I no longer have this problem. I upgraded from f31 to f32 on 2020-03-18. Both mutter and gnome-shell have been updated since then. I can't say after which of those updates it stopped happening.

Comment 11 Thomas Petazzoni 2020-03-30 11:52:04 UTC

Thanks for the feedback. Unless I misunderstood, Fedora 32 is not yet released, so I have not updated at this point. Wouldn't it make sense to also fix the issue in Fedora 31 ?

Comment 12 Alex Scheel 2020-03-30 14:19:53 UTC

Abrahm, it looks like this was fixed upstream via a patch that likely has landed in F32:

https://gitlab.gnome.org/GNOME/mutter/-/commit/23da6c2426932dcb2057849eec9e1d79c34fc405


Florian, can we get the fix for this backported? Thanks!

Comment 13 Alex Scheel 2020-04-29 19:32:45 UTC

I can confirm this is fixed in F32's GNOME. I'll leave this open on the off chance we can get a backport to F31.

Comment 14 Fedora Update System 2020-04-30 15:48:51 UTC

FEDORA-2020-d29c22c817 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d29c22c817

Comment 15 Fedora Update System 2020-05-01 05:03:38 UTC

FEDORA-2020-d29c22c817 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d29c22c817`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d29c22c817

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 16 Fedora Update System 2020-05-05 07:53:22 UTC

FEDORA-2020-d29c22c817 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.