Bug 502862

Summary:	Windows lose focus in 2 steps, causing visible delay
Product:	[Plasma] kwin	Reporter:	Ilya Bizyaev <bizyaev>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	xaver.hugl
Priority:	NOR
Version First Reported In:	6.3.4
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Ilya Bizyaev 2025-04-15 20:30:00 UTC

SUMMARY
Something I can't unsee since noticing it once:

STEPS TO REPRODUCE
1. Open a maximized window, like your web browser.
2. Open a regular (non-maximized) server-side decorated window, e.g. Dolphin or Telegram.
3. Click the background maximized window to make it active.

OBSERVED RESULT
You can see that the foreground window loses its focus in two distinct steps:
* The window is first rendered as inactive (desaturated title bar).
* Only then is it hidden behind the maximized one.

EXPECTED RESULT
As a user, I shouldn't have to wait for the window to be rendered as inactive first when it is going to be fully covered anyway. When clicking the maximized window, I expect the previously active one to disappear immediately.

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20250403
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.2
Kernel Version: 6.14.0-1-default (64-bit)
Graphics Platform: Wayland
Processors: 32 × Intel® Core™ i9-14900K
Memory: 62.5 ГиБ of RAM
Graphics Processor: NVIDIA GeForce RTX 4070

ADDITIONAL INFORMATION

Comment 1 Bug Janitor Service 2025-04-15 20:33:41 UTC

Thank you for the bug report!

However Plasma 6.2.4 is no longer eligible for support or maintenance from KDE; supported versions are 5.27. (LTS), and 6.3 (non-LTS) or newer. Please upgrade to a supported version as soon as your distribution makes it available to you. Plasma is a fast-moving project, and bugs in one version are often fixed in the next one.

If you need support for Plasma 6.2.4, please contact your distribution, who bears the responsibility of providing support for older releases that are no longer supported by KDE.

If you can reproduce the issue after upgrading to a supported version, feel free to re-open this bug report.

Comment 2 Ilya Bizyaev 2025-04-15 20:36:58 UTC

Wrong version selected

Comment 3 Zamundaaa 2025-04-16 12:33:58 UTC

This is just how the new window action works - the window gets activated on click, and only raised on release. It would otherwise be much more difficult to drag something from the maximized window to the non-maximized one.

If you like the old behavior more, you can still choose the old window action ("activate, raise and pass click").

Comment 4 Ilya Bizyaev 2025-04-16 13:33:53 UTC

I don't fully understand this explanation, but I just tried setting Window Management > Window Actions > Inactive Inner Window Actions > Left click to "Activate, raise and pass click", and it does something else: it now takes two clicks to switch to the maximized browser, one to give it focus and another to make it cover Dolphin. (This is on a laptop with Plasma 6.3.0, I can re-test with the 6.3.4 PC later) 

I also wonder if this logic applies to touchpads at all: a tap is both a click and a release, and holding the finger down results in no click triggered.

Comment 5 Ilya Bizyaev 2025-04-16 19:27:45 UTC

• Confirmed with a mouse that the “2 steps” I see are indeed because of click and release.
• Understood how this helps implement drag-and-drop. I guess this is fine then, knowing this happens for a reason makes it feel better :)

But that “Activate, raise and pass click” option also results in this strange two-click behavior on 6.3.4, so not what I want. Does it work as intended? I've never had that behavior in the past.