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
Summary: | GNOME on F31: Switching Workspace results in "Ctrl+Alt+Up" key press getting sent to active application | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alex Scheel <ascheel> |
Component: | gnome-shell | Assignee: | Florian Müllner <fmuellner> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 31 | CC: | abrahm.scully, berrange, canyon, fmuellner, gnome-sig, guidomureddu, jacob.kroon, jadahl, mclasen, otaylor, philip.wyett, pjones, redhat, renan.ifce, thomas.petazzoni, vincent.54.leroy |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-05-05 07:53:22 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Alex Scheel
2019-11-08 16:32:02 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... 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. 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). 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. 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. 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. 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. FWIW, I'm only seeing it on the left control key on my Kinesis Advantage keyboard. The right control key works properly. 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? 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. 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 ? 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! 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. FEDORA-2020-d29c22c817 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d29c22c817 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. 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. |