Bug 440540 - Toggle raise lower no longer lowers windows
Summary: Toggle raise lower no longer lowers windows
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.20.5
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2021-08-03 07:18 UTC by Aaron Williams
Modified: 2024-10-01 14:00 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.2.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Williams 2021-08-03 07:18:08 UTC
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
Comment 1 Bill Crawford 2021-10-29 23:23:48 UTC
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 :)
Comment 2 Bill Crawford 2021-10-30 16:56:23 UTC
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).
Comment 3 DHCP Easyness 2021-12-18 23:29:52 UTC
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)
Comment 4 Rickard Westman 2023-06-13 16:21:39 UTC
Confirming this still happens with kwin 5.24.7 on Kubuntu 22.04 (X11).
Comment 5 Nate Graham 2023-06-20 19:19:06 UTC
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!
Comment 6 Rickard Westman 2023-06-21 19:20:54 UTC
(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.
Comment 7 Nate Graham 2023-06-21 19:22:47 UTC
It is indeed.
Comment 8 Jarek Janik 2023-10-11 04:08:11 UTC
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.
Comment 9 Bug Janitor Service 2024-09-26 00:03:49 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6504
Comment 10 Bug Janitor Service 2024-10-01 08:11:14 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6543
Comment 11 Vlad Zahorodnii 2024-10-01 10:12:27 UTC
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
Comment 12 Vlad Zahorodnii 2024-10-01 10:13:27 UTC
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