SUMMARY I have assigned Ctrl+Alt+F to toggle whether or not a window is raised to the front with focus follows mouse. Recently this stopped working. While it will bring a window to the front, it will not toggle and send it back if it is already in front. STEPS TO REPRODUCE 1. Set focus follows mouse 2. Assign keystroke in KWin for Toggle Window Raise/Lower (I use Ctrl+Alt+f) 3. Move cursor over window in the back and type keystroke 4. Window should move to the front 5. Type keystroke again on the window in front. The window should move back but this does not work. I might add that I have a different keystroke I added to lower the window and this DOES work. OBSERVED RESULT Toggle only brings the window to the front, it does not send it back EXPECTED RESULT Toggle should send lower the top window under the cursor SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 5.20.5 (available in About System) KDE Plasma Version: KDE Frameworks Version: 5.84.0 Qt Version: 5.15.2 KWin: 5.22.3-lp152.419.1 Distro: OpenSUSE 15.2 ADDITIONAL INFORMATION
Same problem has recently appeared for me when using Meta + right mouse button for the same purpose (no longer lowering, only raising). This is on Fedora (34), so the bug is probably not distro-specific :)
Ah, more info: looks like there was a "keep above" window elsewhere on the screen. Please ignore previous comment (although this is still a bug: having raised it "almost to the top" it should be possible to send it back again).
I have this problem too. Only happens when at least one window on the screen is 'always on top' 'Keep Above Others'. I use Kubuntu 21.10 (kwin 5.22.5)
Confirming this still happens with kwin 5.24.7 on Kubuntu 22.04 (X11).
I'm afraid Plasma 5.20.5 is unfortunately no longer eligible for support or maintenance from KDE. Plasma is a fast-moving project, and bugs in one version are often fixed in the next one. Please update to Plasma 5.27 as soon as your distro offers it to you. For what it's worth, the issue as described here works for me with your steps to reproduce. If you need support for Plasma 5.20.5, please contact your distro, who bears the responsibility of providing support for older non-LTS releases. If this issue is still reproducible for you in Plasma 5.27, feel free to re-open this bug report. Thanks for understanding!
(In reply to Nate Graham from comment #5) > I'm afraid Plasma 5.20.5 is unfortunately no longer eligible for support or > maintenance from KDE. (...) > If this issue is still reproducible for you in Plasma 5.27, feel free to re-open this bug report. What about Plasma 5.24.7 – is that as unmaintained as 5.20.5? Because I see the bug with Kubuntu 22.04 running Plasma 5.24.7.
It is indeed.
This bug is still present in 5.27. This bug has been introduced by 9577423dfa "Remove most_recently_raised micro optimization" (May 2021). The most_recently_raised field was not just a micro optimization, it used to allow normal windows to be "considered" top-most (or "raised") even in the presence of KeepAbove windows. I have a fix for it (2 actually), merge requests are on their way.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6504
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6543
Git commit 5a0026a9eba79574eb0d3646eabb63cd564158e5 by Vlad Zahorodnii, on behalf of Jarek Janik. Committed on 01/10/2024 at 08:09. Pushed by vladz into branch 'Plasma/6.2'. Fix "Toggle raise and lower" functionality Fix "Toggle raise and lower" functionality for a case when there are windows in higher layers present on the same desktop; a window that is being acted upon could never be top-most in such a case, which prevented it from being lowered by "Toggle raise and lower" action. Checking if a window is top-most now uses unconstrained_stacking_order list, which reflects user-requested stacking window order, but doesn't know anything about layers, and that in turn allows any window that user has raised most recently to be lowered by "Toggle raise and lower" (even if this window is not actually top-most, because of windows in higher layers). (cherry picked from commit dad57ad0a0afe3fe249b0d39df5e511efe4960c0) M +1 -1 src/layers.cpp https://invent.kde.org/plasma/kwin/-/commit/5a0026a9eba79574eb0d3646eabb63cd564158e5
Git commit dad57ad0a0afe3fe249b0d39df5e511efe4960c0 by Vlad Zahorodnii, on behalf of Jarek Janik. Committed on 01/10/2024 at 07:52. Pushed by vladz into branch 'master'. Fix "Toggle raise and lower" functionality Fix "Toggle raise and lower" functionality for a case when there are windows in higher layers present on the same desktop; a window that is being acted upon could never be top-most in such a case, which prevented it from being lowered by "Toggle raise and lower" action. Checking if a window is top-most now uses unconstrained_stacking_order list, which reflects user-requested stacking window order, but doesn't know anything about layers, and that in turn allows any window that user has raised most recently to be lowered by "Toggle raise and lower" (even if this window is not actually top-most, because of windows in higher layers). M +1 -1 src/layers.cpp https://invent.kde.org/plasma/kwin/-/commit/dad57ad0a0afe3fe249b0d39df5e511efe4960c0