Bug 500782

(In reply to kdebugs from comment #0)
> SUMMARY
> Some applications are being sent keyboard input when they are not the window
> in focus.
> 
> STEPS TO REPRODUCE
> 1. Open Chromium, and maximize on screen one.
> 2. Open Firefox and maximize on screen two.
> 3. Use the keyboard in Firefox to type a message, and use the arrow keys to
> move around in text. You can also try ctrl+f and see the page search open
> and search in both browsers.
> 
> OBSERVED RESULT
> Inputs are duplicated to Chromium on the first display, despite not being
> the active window.
> 
> EXPECTED RESULT
> Inputs should only be sent to Firefox or the currently active window on the
> second display.
> 
> SOFTWARE/OS VERSIONS
> Operating System: Fedora Linux 41
> KDE Plasma Version: 6.3.0
> KDE Frameworks Version: 6.11.0
> Qt Version: 6.8.2
> Kernel Version: 6.12.13-200.fc41.x86_64 (64-bit)
> Graphics Platform: Wayland
> Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor
> Memory: 128.0 GiB of RAM
> Graphics Processor: AMD Radeon RX 6900 XT
> 
> ADDITIONAL INFORMATION
> The problem goes away when another window is in the foreground in front of
> Chromium, my kinfo konsole window for instance. I haven't found any other
> applications exhibiting this behavior yet, but I haven't exhausted the
> possibilities.
> 
> Marked as major severity because of clear security implications.

Was not able to replicate on my system. I do notice several key differences between our systems (versions and distros), so this may be part of the reason. What are your focus settings? separate screen focus is an option and may be related, or depending on your settings it may have to do with the position of your cursor. marking needsinfo waitingforinfo for now.

Created attachment 178926 [details]
Window behavior settings.

Created attachment 178927 [details]
Window behavior settings.

Created attachment 178928 [details]
Window behavior settings.

Created attachment 178929 [details]
Window behavior settings.

Created attachment 178930 [details]
Window behavior settings.

(In reply to minelorderagon16 from comment #1)

> Was not able to replicate on my system. I do notice several key differences
> between our systems (versions and distros), so this may be part of the
> reason. What are your focus settings? separate screen focus is an option and
> may be related, or depending on your settings it may have to do with the
> position of your cursor. marking needsinfo waitingforinfo for now.

I added screenshots of the Window behavior settings. I also can't seem to trigger it again myself. I'll update with a new comment status and info if I figure out how to trigger it more consistently.

(In reply to kdebugs from comment #7)
> (In reply to minelorderagon16 from comment #1)
> 
> > Was not able to replicate on my system. I do notice several key differences
> > between our systems (versions and distros), so this may be part of the
> > reason. What are your focus settings? separate screen focus is an option and
> > may be related, or depending on your settings it may have to do with the
> > position of your cursor. marking needsinfo waitingforinfo for now.
> 
> I added screenshots of the Window behavior settings. I also can't seem to
> trigger it again myself. I'll update with a new comment status and info if I
> figure out how to trigger it more consistently.

ok, i'll mark it as worksforme until then.

I have new information on this. I still don't have a definitive way to reproduce this, but I've narrowed down the circumstances. It may be related to an issue with scaling. I keep having issues with Chromium scaling resetting back to 100% from 150%. This can be fairly reliably triggered by locking the session and signing back in. The only way to reset the scaling without restarting Chromium is by going into full screen mode, then exiting it. Somewhere along the line, this causes it to receive input directed towards other QT applications* that it should not be receiving.

I'm not sure what exact circumstance causes Chromium to pick up this input that it shouldn't be receiving, but I only seem to encounter it while a video is actively playing, and only when I am inputting into another QT app. I.e if I type into Steam while the video is playing in Chromium, the input doesn't get sent to Chromium, whereas in Firefox or Discover, or Kwrite, it does.

I'm leaving the session open for now, and not restarting Chromium, in case anyone here wants me to try something.

*I'm not sure what the proper term is, but any application that uses native window decorations?

(In reply to kdebugs from comment #9)
> I have new information on this. 

Thanks for the additional information. Using the setup from your latest comment, I tested on Plasma 6.3.2 and git-master
I was unable to reproduce the original bug, or the zoom bug with Chromium at all.

Something you might try is to create a new user and see if you can reproduce with that. If you can't, there may be some config or cache item that's at play.

(In reply to TraceyC from comment #10)
> 
> Thanks for the additional information. Using the setup from your latest
> comment, I tested on Plasma 6.3.2 and git-master
> I was unable to reproduce the original bug, or the zoom bug with Chromium at
> all.
> 
> Something you might try is to create a new user and see if you can reproduce
> with that. If you can't, there may be some config or cache item that's at
> play.

I plan to look into filing a ticket for the scaling bug once I've determined whether it's a Chromium or a Plasma bug. I suspect triggering that might be a prerequisite to triggering this. There might also be a time component to this, as I haven't encountered it on a super fresh Chromium process yet.

Are there any additional debug settings/flags I can set in plasma/kwin that might also help in identifying this? I plan to start launching Chromium from a terminal so I can see any output it might generate.

🐛🧹 ⚠️ 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!