| Summary: | Xwayland apps get Tab keyboard events even when they should be filtered out by event filter | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | mailport+kdebugs |
| Component: | input | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | alex, aurelien, bluelkshell, brunoades, bugs.kde.org, cameron.w, claudio, contact, descartavel1, dzert127, elman, figueroa628, greg.martyn, h_dieter, jadaml, jbeckman1974, julian, kde, kde, kdebugs, kdedev, mailport+kdebugs, mg05182-kde, moore.bryan, moslike6, nate, nyanpasu64, postix, ricardo, sami.kyostila, schierkevin, sebastian.pb31, sebbarg, srikarbharadwaj0, superrudra1601, tandiv15.bansal, tchiot.ludo, vaiogames18, web, xaver.hugl, xnaxdy, Xtian7489 |
| Priority: | HI | Keywords: | regression |
| Version: | 6.0.3 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=478556 | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/8fd4476ff1848ce7ce4d3573224fc4893ae8339d | Version Fixed In: | 6.2.0 |
| Sentry Crash Report: | |||
| Attachments: |
Video of a window receiving TAB characters while cycling windows.
Video of a key being sent to a XWayland app after it's released in Wayland. Video of the bug occurring on Fedora Plasma 6.3.0. |
||
|
Description
mailport+kdebugs
2024-04-03 16:23:06 UTC
Can confirm, though it only happens if you set X11 apps to always be able to read all keystrokes (In reply to Zamundaaa from comment #1) > Can confirm, though it only happens if you set X11 apps to always be able to > read all keystrokes Wow - thanks Zamundaaa. That actually fixes my problem (even though I had the option "Any key typed while Control/Alt/Meta are pressed" selected). But switching to "Never" completely fixes it. You can't believe how annoying the last week was, I think in every project of mine are now random tabs committed. Really thank you - lol, send me you postal address and I'll mail you a box of chocolate. Also happens for me when using the overview feature or desktop grid. First input gets properly intercepted while all following keys "leak" through. *** Bug 486263 has been marked as a duplicate of this bug. *** Trivial way to reproduce: Focus an XWayland window and Alt+Tab with default XWayland snooping settings. The app gets sent tab keys. *** Bug 489325 has been marked as a duplicate of this bug. *** *** Bug 489382 has been marked as a duplicate of this bug. *** *** Bug 488870 has been marked as a duplicate of this bug. *** This was exposed by changing the XWayland snooping move away from "Never". *** Bug 489609 has been marked as a duplicate of this bug. *** *** Bug 489631 has been marked as a duplicate of this bug. *** Created attachment 171308 [details]
Video of a window receiving TAB characters while cycling windows.
I see it as well. Here is a simple way to reproduce using vscode (it affects chrome as well, but is very easy to see in vscode) 1. Settings -> Task Switcher: disable "show selected window" (makes it easier to see what is happening) 2. start vscode with an empty document 3. press alt-tab repeatedly and observe the tab character "bleeds through" to vscode. *** Bug 489757 has been marked as a duplicate of this bug. *** Add backtick to the list: when pressing Alt+` + ` (backtick twice) the original window gets the backtick. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6074 *** Bug 490754 has been marked as a duplicate of this bug. *** I actually started to report new bug when I stumbled upon this one, so here is my description which seems pretty much like what is described here:
When I use Alt+Tab to switch windows, keystrokes are sent to last active window and appear as spaces. For example, I use RubyMine, have code `<MessageBox messages={messages}/>` and I leave cursor between `=` and `{`. Then I use Alt+Tab to loop through all open windows (13 window) and get back to RubyMine, I have code `<MessageBox messages= {messages}/>` so 25 spaces are added.
So far I have seen this issue with RubyMine, Typora.
Slack and Spotify act as if they are receiving Tab keystrokes.
All of these applications are xclients.
Git commit 8fd4476ff1848ce7ce4d3573224fc4893ae8339d by David Edmundson. Committed on 02/08/2024 at 09:31. Pushed by davidedmundson into branch 'master'. wayland: Move XWayland key forwarding into a filter We optionally send some keys to xwayland through the filter when no x11 client has focus. This allows shortcut handling in X11 apps to work. When kwin is grabbing keys we don't necessarily want X11 to sniff these keys as things can get out of sync. A key place is the tabbox. The X11 client sill has focus, but xwayland is not active. This means we pass tab keys to X which then go to application incorrectly. Part of this patch changes the tabbox filter to not intercept the alt key release event. This ensures xwayland's concept of pressed modifiers stays in sync. M +36 -0 autotests/integration/x11keyread.cpp M +1 -0 src/input.cpp M +1 -0 src/input.h M +50 -49 src/xwayland/xwayland.cpp M +2 -2 src/xwayland/xwayland.h https://invent.kde.org/plasma/kwin/-/commit/8fd4476ff1848ce7ce4d3573224fc4893ae8339d *** Bug 491287 has been marked as a duplicate of this bug. *** I see that it "Version fixed in" says 6.2.0, the next major release, which is still some time off. Would it be possible to cherry-pick it into some of the 6.1 bugfix releases? (In reply to ⭐️NINIKA⭐️ from comment #21) > I see that it "Version fixed in" says 6.2.0, the next major release, which > is still some time off. > > Would it be possible to cherry-pick it into some of the 6.1 bugfix releases? At Nate's blog I noticed that this only happens with default setting "When Alt+Tabbing through windows, tab keystrokes no longer leak into XWayland-using apps when using default XWayland app keyboard snooping setting". So I just went to settings and selected to never send any keystrokes to X11 apps and that works for me. I don't use any X11 app that would need those keystrokes. *** Bug 492272 has been marked as a duplicate of this bug. *** *** Bug 492116 has been marked as a duplicate of this bug. *** *** Bug 492037 has been marked as a duplicate of this bug. *** (In reply to elman from comment #22) > (In reply to ⭐️NINIKA⭐️ from comment #21) > > I see that it "Version fixed in" says 6.2.0, the next major release, which > > is still some time off. > > > > Would it be possible to cherry-pick it into some of the 6.1 bugfix releases? Please KDE devs, if it's not too invasive it'd be nice to have this backported to 6.1.x > At Nate's blog I noticed that this only happens with default setting "When > Alt+Tabbing through windows, tab keystrokes no longer leak into > XWayland-using apps when using default XWayland app keyboard snooping > setting". So I just went to settings and selected to never send any > keystrokes to X11 apps and that works for me. I don't use any X11 app that > would need those keystrokes. Thanks for pointing out that workaround! It never occurred to me to go looking through the settings. I don't know what side effects this setting might have but at least I won't lose my mind now 😁 *** Bug 492491 has been marked as a duplicate of this bug. *** *** Bug 493956 has been marked as a duplicate of this bug. *** *** Bug 492361 has been marked as a duplicate of this bug. *** *** Bug 493221 has been marked as a duplicate of this bug. *** *** Bug 493386 has been marked as a duplicate of this bug. *** This does not appear fixed in 6.2.3 on Fedora 41. *** Bug 494590 has been marked as a duplicate of this bug. *** Created attachment 177983 [details] Video of a key being sent to a XWayland app after it's released in Wayland. I'm still getting this bug on KDE Plasma 6.2.5 on Fedora 41. To understand why the bug happens, I installed screenkey, a X11-based program which displays keystrokes on-screen. Since it's a X11 app running under XWayland, it only sees keystrokes delivered to XWayland apps. ## Reproduction To set up keystroke visualization, in Screenkey settings I checked "Persistent window", and under KDE "Special Application Settings" I set all windows from Screenkey to be above other windows. Then I restarted screenkey, dragged the window to a convenient location, then opened a Wayland app (Firefox) and an X11 app (Obsidian Flatpak). To reproduce the bug, I typed into Wayland Firefox while watching screenkey to see what keystrokes it's receiving. I also moved my mouse in circles over X11 Obsidian, which makes XWayland send events to screenkey more quickly. I used GPU Screen Recorder in replay mode to record the screen while I looked for bugs, and in recording mode to capture a screencast of the bug happening. My findings: ## Behavior - Enter, Backspace, Tab, and arrow/Home/End/Page Up/Down keystrokes are delivered to screenkey immediately. If you're not moving the mouse, they get delayed until the next modifier keystroke (like Ctrl or Shift) or a periodic timer. - Modifier shortcuts (like Ctrl+A) are delivered to screenkey immediately. If you're not moving the mouse, they're delayed until you release Ctrl. - If I release Ctrl before A, XWayland usually enters a state where it sends an endless string of A keystrokes to screenkey (which refreshes faster if you're moving your mouse over a X11 app); I think the key repeats forever because kwin_wayland fails to deliver the A key release to XWayland. While the key is repeating, if I mouse-click into a X11 (XWayland) app, there is a 10-50% chance that an erroneous A key gets delivered to the app. I think this happens if a key repeat gets delivered to the app before XWayland realizes A is no longer being pressed. I've reproduced this bug with alphabetic and symbol keys (like ; semicolon). I'm not sure this bug happens with *tab* events after Plasma 6.2; Tab is always sent to XWayland (so letting go of a modifier does *not* cause the key release to not be sent), Alt+Tab does not appear on Screenkey at all, and Ctrl+Tab does not trigger endless repeats on screenkey if I release Ctrl before Tab (I think the endless repeats are what causes stray keystrokes). In any case I'm still posting this report under this bug; I reported the issue with alphabetic keys instead of Tab at Bug 493956, but that got closed as a duplicate of this. ## Fix I'm guessing the fix is that if the user presses Ctrl+A, the A keypress "belongs to a shortcut" and the key release is unconditionally delivered to XWayland, even if Ctrl has been released already. Also, if the user presses A and it's not delivered to XWayland, then presses Ctrl and releases A, it may not be necessary to deliver the key release if you don't deliver key-held events; I don't know if you do or not, or what behavior is ideal. I think this behavior is a result of KDE's implementation of "Allow legacy X11 apps to read keystrokes typed in all apps:" "As above, plus any key typed while the Control, Alt, or Meta keys are pressed" option. Unfortunately this is the default value of the setting. Hopefully this analysis helps find out *why* stray keys are sent to XWayland apps, and fix keys being stuck on repeat on XWayland and being sent to apps when focused. I wonder if there's a similar bug where if you hold Ctrl+A on a Wayland app and click on a X11 app, KWin sends a stray Ctrl+A to the app. I don't think this bug exists, since when you click on a X11 app, screenkey reports a single A keystroke (not a Ctrl+A) and spends a second before repeating Ctrl+A presses. I also tried this procedure 20+ times and did not see the bug. Operating System: Fedora Linux 41 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Kernel Version: 6.12.9-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-3570K CPU @ 3.40GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4000 Manufacturer: M&A Technology Product Name: DB75EN__ Reopening, given the new information. Thanks for the detailed troubleshooting! . I've been trying for a while to reproduce with the steps in #34 and I'm failing to hit an issue with unexpected 'a' keys being sent to an application after releasing keys. There have been changes in kwin in this area between your testing and current master, it would be useful if you can confirm you still have an issue with 6.3 is out. I tested this on git-master and Plasma 6.2.5 Unfortunately, I can't test this with screenkey. Note that Screenkey is not supported under Wayland On Solus, it doesn't have a system tray icon, so I can't get to its settings. It was introducing lag, and preventing keystrokes from getting to applications. It made the system fairly unusable. Without screenkeys, those same keystrokes were input into Wayland windows as expected, so IMO it's not a reliable testing tool in Wayland. TEST STEPS - From original post - Alt + tab + tab 1. Open a xwayland application - used Obsidian Notes 2. Set the input focus into the textarea. 3. Press Alt+Tab+Tab to switch two windows further (aka HOLD-ALT PRESS-TAG PRESS-TAB RELEASE-ALT) 4. Go back to the original window and observe that one tab was pressed Results: git-master: Unable to reproduce 6.2.5: I do see undesirable results When Obsidian is focused and I press Alt Tab Tab, the window goes white and a Tab character is inserted in the note After doing that a couple of times, it stopped happening. TEST STEPS - From comment #34 Used Obsidian and Kate to test 1. Set the cursor in Obsidian to be inside a note 2. Type text into Kate. Use various shortcuts (Ctrl-A Ctrl-C Ctrl-Shift-S) 3. Alt + tab + tab to other apps and Alt+tab back 4. Entered Enter, Backspace, Tab, and arrow/Home/End/Page Up/Down keystrokes Results: git-master: Unable to reproduce the bug, no stray keys appears in Obsidian 6.2.5: Unable to reproduce I have noticed stray characters in Obsidian in Plasma 6.2.5, intermittently Steps: 1. Have Obsidian Notes or another xwayland app open, that can accept text 2. Go to a Wayland window and use Ctrl+C to copy some text 3. Switch back to the Obsidian window by clicking it Observed: A 'c' character is pasted into Obsidian without me doing anything It has been intermittent, sometimes happening a few times in a row, and then not happening for a while I've been testing the stray character thing on and off all day and can't reproduce on git-master at all. This potentially fixed in 6.3.0 (In reply to TraceyC from comment #40) > I've been testing the stray character thing on and off all day and can't > reproduce on git-master at all. > This potentially fixed in 6.3.0 I can confirm that the upgrade to 6.3.0 fixed this issue for me. Created attachment 178241 [details]
Video of the bug occurring on Fedora Plasma 6.3.0.
The stray character bug still happens on Plasma 6.3.
When I set KDE Wayland's X11 key visibility to the default of "As above, plus any key typed while the Control, Alt, or Meta keys are pressed", Screenkey shows the "X11 never sees the key is released" bug is still happening unchanged, and the key repeats can still register as characters in Obsidian.
Operating System: Fedora Linux 41
KDE Plasma Version: 6.3.0
KDE Frameworks Version: 6.10.0
Qt Version: 6.8.2
Kernel Version: 6.12.11-200.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-3570K CPU @ 3.40GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Intel® HD Graphics 4000
Manufacturer: M&A Technology
Product Name: DB75EN__
Thanks for the updated information and video. That clearly shows the problem happening. Good catch on the related setting. I re-tested in 6.3.0 and git-master I checked KDE Wayland's X11 key visibility, verified "As above, plus any key typed while the Control, Alt, or Meta keys are pressed" (Settings->Application Permissions->Legacy X11 App Support) I used Firefox and Obsidian Notes and repeated what I did in comment #38 6.3.0: I can still reproduce, intermittently. Sometimes Ctrl+C did not always result in a 'c' in Obsidian. Ctrl+f in Firefox did result in an 'f' character in Obsidian. git-master: X11 keystrokes had been set to "Always". Changed to the default. Still unable to reproduce at all. 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! See previous comments. I still see this behaviour with the default settings at least when Alt+Tabbing from a Wayland window to an XWayland window, e.g. when switching from Okular to Opera, the browser's menu opens due to the Alt key leaking. Updated system info: Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.5-200.fc41.x86_64 (64-bit) Graphics Platform: offscreen Processors: 12 × AMD Ryzen 5 5600H with Radeon Graphics Memory: 15.0 GiB of RAM Sorry, kinfo but this time logged in graphically and not via ssh: Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.5-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600H with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: AMD Radeon Graphics |