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.
FWIW I haven't succeeded at reproducing the issue with those exact steps. :/
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.)
I started seeing this today in git-master, copying from Firefox to Obsidian Notes (flatpak)
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
(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"?
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.
(In reply to nyanpasu64 from comment #6) > If I set "Allow legacy X11 apps to read keystrokes typed in all apps:" to Thank you!
(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
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).
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"
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