Bug 457457

Summary:	Strange window activation behavior
Product:	[Plasma] kwin	Reporter:	Alex <allo>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	akselmo, dylan.piergies, john.kizer, nate
Priority:	NOR	Keywords:	regression
Version First Reported In:	5.25.3
Target Milestone:	---
Platform:	Other
OS:	Other
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Alex 2022-08-03 18:06:04 UTC

Since the upgrade to 5.25.3, I got a strange problem with activation on mouse contact (mouse preferred) and Focus steal prevention, I think.

Sometimes when I click, for example, a link in an application, it opens in Firefox and Firefox does not take the focus but comes to front. When I then move the cursor to the title bar, the previous window comes to front (but doesn't have focus).

Other observed variants include that I have, for example, a non-maximized terminal window in front of a maximized window. When I move the cursor from the panel to the maximized window, suddenly the maximized window comes to front.
The strange thing then is, when I click the terminal window item in the (icons-only-)taskbar, it minimizes the terminal (seems correct), but clicking it again brings it to front and instantly covers it with the maximized window again.

Doing this again and again, after some tries the terminal stays in front and sometimes I can even move the cursor over the maximized window to the free-floating terminal window.

Sometimes I also get the behavior when using click-to-focus and trying to bring the previously hidden floating terminal window to front. Both when it is hidden and when it is minimized, it shortly appears on front and then is covered even when the mouse is still on the taskbar item.

I would have suspected that the maximized window is somehow aggressive about being in front, but the only thing I changed is the KDE upgrade (together with some other X11 upgrades in Debian) but not the programs with the weird behavor.

Sorry when the post looks a bit incoherent, but I am also struggling to find out which conditions cause this behavor.

SOFTWARE/OS VERSIONS
Operating System: Debian GNU/Linux
KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Graphics Platform: X11

Comment 1 Alex 2022-08-03 18:08:44 UTC

The window being maximized doesn't seem neccessary either. I tried a window that is resized to full size and not maximized and get the same behavor.

Focus follow mouse seems to be related in the case when I can move the cursor over the background window to the floating window and the floating window gets hidden in the moment the cursor touches it.

So it seems to be related to window focus, both from focus-follow-mouse and from simple activation via the taskbar.

Comment 2 Alex 2022-08-04 06:50:33 UTC

floating windows (together with activation by mouse contact) only make it easier to trigger the bug, but I just had similar behavor with two maximized windows.

Comment 3 Dylan Piergies 2024-03-08 20:45:15 UTC

I'm seeing a problem that's likely related (or the same issue).

Sometimes mouse events seem to be reaching the window behind the window I'm pointing at.

I don't see windows being raised as the reporter described but I have: `clickRaise: false` and `commandWindow1: MouseActivateAndPassClick` which may explain that. If I set `clickRaise: fatruelse` and/or `commandWindow1: MouseActivateRaiseAndPassClick` these options (which is the default) I would expect to see exactly the reported behaviour.

Comment 4 Akseli Lahtinen 2025-06-05 11:34:37 UTC

> Sometimes mouse events seem to be reaching the window behind the window I'm pointing at.

I've noticed this with certain apps, usually ones with somekind of embedded browser. 
Freetube and steam come to mind. Even if the window is in the background, it still takes inputs and any window on front
of it does not. I think it happens with windows that request attention in task manager, so their background in the taskbar
becomes orange.

Somekind of disconnect between visuals and behavior? 

Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.80
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.0
Kernel Version: 6.15.0-61.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 16 GiB of RAM (15.5 GiB usable)
Graphics Processor: AMD Radeon RX 6600

Comment 5 John Kizer 2025-06-16 05:06:50 UTC

Could the reporter for this, or other commenters if they have a handle on what's being described, please list out some steps that can be taken to reproduce the behavior described in this report? Please see https://community.kde.org/Get_Involved/Issue_Reporting#Steps_to_Reproduce for a reference.

Those steps, along with descriptions of the observed and expected results, is necessary to make sure that folks are investigating the right issue.

Thanks!

Comment 6 Bug Janitor Service 2025-07-01 03:47:34 UTC

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

Comment 7 Alex 2025-07-01 07:52:17 UTC

I don't think I've noticed the problem for a long time.
Currently still on X11, can't tell for Wayland.

Comment 8 Akseli Lahtinen 2025-07-01 08:35:48 UTC

I will close this issue for now, but feel free to reopen it (or make new one) in case you encounter issues again.

Thanks!