Bug 510404

Summary:	XWayland apps get stray keystrokes if you release modifier before shortcut character
Product:	[Plasma] kwin	Reporter:	nyanpasu64 <nyanpasu64>
Component:	xwayland	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	CONFIRMED ---
Severity:	normal	CC:	kde49861515, kdedev, nate, safinaskar
Priority:	NOR
Version First Reported In:	6.4.5
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Video of the Ctrl+A bug happening on Plasma 6.5.80.

Description nyanpasu64 2025-10-08 20:27:30 UTC

Created attachment 185615 [details]
Video of the Ctrl+A bug happening on Plasma 6.5.80.

SUMMARY
If you press a shortcut like Ctrl+C in a Wayland app, then release the modifier Ctrl before the letter, the key remains held down in XWayland and can randomly be sent to a X11 app when you click on it.

STEPS TO REPRODUCE
1. In Legacy X11 App Support, ensure "Allow legacy X11 apps to read keystrokes typed in all apps:" is set to the default of "As above, plus any key typed while the Control, Alt, or Meta keys are pressed".
2. Open a Wayland window (like a KDE app) and a X11 window (like Flatpak Obsidian).
3. Focus the Wayland app, type Ctrl+C, and release Ctrl before C.
4. Click on the X11 app.

OBSERVED RESULT
Randomly a C keystroke will be sent to the X11 app. This may take many tries.

To see what keystrokes are delivered to X11 apps, you can install Screenkey from your distro package manager or by running `uvx https://gitlab.com/screenkey/screenkey.git`, then use Window Rules to set the popup to "Keep above other windows", "No titlebar and frame", and "Accept focus" force = No.

I found that if I release Ctrl before C, XWayland usually enters a state where it sends an endless string of C keystrokes to screenkey (these may not be visible until you move your mouse over a X11 app); I think the key repeats forever because kwin_wayland fails to deliver the C key release to XWayland. When you click on a X11 app, there's a chance a key repeat gets delivered to the app before XWayland realizes C is no longer being pressed and stops repeating it.

EXPECTED RESULT
XWayland apps should receive key release events regardless of modifier state, if the original key press event was received (eg. because modifier was held, or before changing the "Allow legacy X11 apps to read keystrokes typed in all apps:" option).

SOFTWARE/OS VERSIONS
This reproduces on Plasma 6.4.5, as well as 6.5.80 from KDE Linux 2025-09-21.

Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2
Kernel Version: 6.16.10-200.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-8559U CPU @ 2.70GHz
Memory: 16 GiB of RAM (15.5 GiB usable)
Graphics Processor: Intel® Iris® Plus Graphics 655
Manufacturer: Intel(R) Client Systems
Product Name: NUC8i7BEH
System Version: J72992-303

ADDITIONAL INFORMATION

The "possible duplicates" list pointed to Bug 478705, which has a command `xinput test-xi2 --root` to log received keyboard/mouse events in the terminal. By running this command and doing testing, I found that if we press C (not received) then Ctrl, then release C, xinput never receives the C release event even though Ctrl is being held. I wonder if it's kwin filtering the unpaired release before reaching XWayland, or XWayland/xinput rejecting a stray key release KDE mistakenly sends.

Previous testing at https://bugs.kde.org/show_bug.cgi?id=484992#c34 and https://bugs.kde.org/show_bug.cgi?id=484992#c59.

Comment 1 Nate Graham 2025-10-09 15:54:23 UTC

FWIW I haven't succeeded at reproducing the issue with those exact steps. :/

Comment 2 nyanpasu64 2025-10-09 16:12:09 UTC

When you launch `xinput test-xi2 --root` in a terminal and perform the steps before 4, do you at least get key repeats without C held down? (If you use Konsole as the Wayland app, you may need to type Ctrl-A to avoid killing the program.)

Comment 3 TraceyC 2025-10-10 22:41:15 UTC

I started seeing this today in git-master, copying from Firefox to Obsidian Notes (flatpak)

Comment 4 Askar Safin 2025-10-14 05:41:27 UTC

I was able to reproduce this using exact steps in "STEPS TO REPRODUCE". The bug is totally reproducible, you just need to have patience.
Try a lot of times, and you will succeed in this.
Try various ways to type that "Ctrl+C". I. e. try to release C right after Ctrl. Also try to release C right after Ctrl, but not quite right after, etc.
I. e. try various durations between releasing C and releasing Ctrl.

I used Chromium 140.0.7339.127 (it is Wayland-native app by default in this version) and xterm (it runs under xwayland) as my test apps.

Operating System: Debian GNU/Linux 13
KDE Plasma Version: 6.3.6
KDE Frameworks Version: 6.13.0
Qt Version: 6.8.2
Kernel Version: 6.12.43+deb13-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × 13th Gen Intel® Core™ i9-13950HX
Memory: 64 GiB of RAM (62.5 GiB usable)
Graphics Processor: Intel® Graphics
Manufacturer: Dell Inc.
Product Name: Precision 7780

Comment 5 Askar Safin 2025-10-14 05:43:24 UTC

(In reply to nyanpasu64 from comment #0)
> SUMMARY

Does this happen if you set "Allow legacy X11 apps to read keystrokes typed in all apps:" to "Never"?

Comment 6 nyanpasu64 2025-10-14 05:57:35 UTC

If I set "Allow legacy X11 apps to read keystrokes typed in all apps:" to "Never", `xinput test-xi2 --root` never reports keystrokes for Ctrl *or* A entered in a Wayland app, so X11 apps can't get stray keystrokes through the mechanism I described. To confirm, I tried the "Ctrl+A + !Ctrl + !A, click in Obsidian" dance 20 times and did not receive a stray keypress, meaning the bug does not appear to happen.

Comment 7 Askar Safin 2025-10-14 06:28:58 UTC

(In reply to nyanpasu64 from comment #6)
> If I set "Allow legacy X11 apps to read keystrokes typed in all apps:" to

Thank you!

Comment 8 Askar Safin 2025-10-21 09:48:02 UTC

(In reply to nyanpasu64 from comment #6)
> If I set "Allow legacy X11 apps to read keystrokes typed in all apps:" to

And if you set to "Only Meta, Control, Alt and Shift keys"?

(I'm attempting to come up with working configuration for me.)

Thank you in advance

Comment 9 nyanpasu64 2025-10-21 23:31:50 UTC

My preferred workaround is to set it to Always. But I *think* any option other than "any key typed when (modifiers)" is unaffected, since that's the only option that *conditionally* allows keystrokes to be sent to Xwayland (so a key release can be missed).

Comment 10 kde49861515 2025-11-28 00:33:22 UTC

this may be similar to what I'm observing with https://bugs.kde.org/show_bug.cgi?id=511684

my setting is currently "only the meta, control, alt and shift keys", and "listening for mouse buttons" is checked - I need this combination to let Mumble capture push to talk whilst not being in focus, however alt+tab is randomly acting funky causing my mouse forward / back events to be sent to multiple windows and I have to refocus the bugged window to get it to stop

I'll try the "as above, plus any key pressed while the control, alt, or meta key is also pressed" option, and failing that I'll try "always allowed"

Comment 11 kde49861515 2025-12-01 01:23:58 UTC

In my case, the only option that stops the input from being sent to the xwayland windows as well is to set Legacy X11 app support to "disabled". In every other case the input is still being dispatched to the windows that are not in focus