Bug 443237 - focusing a window (with hover to focus) should not change its order on the "recently used" stack
Summary: focusing a window (with hover to focus) should not change its order on the "r...
Status: RESOLVED DUPLICATE of bug 476496
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.22.4
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2021-10-03 01:19 UTC by Adam Fontenot
Modified: 2023-11-03 05:14 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Fontenot 2021-10-03 01:19:30 UTC
SUMMARY

This is a nit, but a major pain point for those using the "focus follows mouse" setting (in Settings > Window Management > Window Behavior > Window activation policy). When you briefly hover over an inactive window, but do not otherwise interact with it, KWin raises the window to the top of its *internal* stack of windows - it doesn't raise the window to the top of the visible windows *on the screen*, but it otherwise behaves as if it *had* done so.

STEPS TO REPRODUCE
1. Set focus follows mouse (mouse precedence) as your window activation policy. Delay focus is 0ms, Focus stealing prevention is Medium.
2. Open three windows. One should be maximized (your browser works fine), two should be small windows some distance apart from each other, and both of these should be on top of the maximized window.
3. Click on one of the small windows to focus it. Move the cursor to the other window (*passing over the background window*) and click on the other window.
4. Press alt-tab (or whatever shortcut you have to activate the task switcher).

OBSERVED RESULT

The window that the task switcher tries to activate is the background window, even though you never interacted with it or tried to raise it.

EXPECTED RESULT

The other small window should be selected by the task switcher. 

This is a very common pattern. You have something like your browser running maximized, and meanwhile you're working with two windows (say, a terminal and a code editor), and you need to copy something from one of these windows and paste it in the other. You try to alt-tab back to the initial window, but unfortunately the brief moment when the background window was focused was enough for KWin to move it to the top of the stack.

Important note: I'm aware that the task switcher has a "stacking order" option. This seemingly does the *opposite* of what I want. When I am in a window on the top of the visible stack, and I alt-tab to go back to the previous window I was using, "stacking order" starts me at the *bottom* of the stack and moves up from there! 

I think it's sensible to have this option for people who want it (after all, if you're not using hover to focus then if "stacking order" worked in top-down fashion then it would - I think - behave identically to "recently used"). So I think the most reasonable understanding of this problem is as a bug in hover to focus: a window should not be considered recently used just because it was focused: it should only be recently used if I interacted with it, e.g. raised it by clicking.

SOFTWARE/OS VERSIONS
Linux: Arch Linux x86_64 (kernel 5.14.5)
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Comment 1 Adam Fontenot 2021-10-08 09:11:43 UTC
I wrote a patch that implements reverse stack ordering. Comments welcome. It works well for me in testing but I think I already see some potential limitations...

https://invent.kde.org/plasma/kwin/-/merge_requests/1507
Comment 2 David Edmundson 2023-09-06 10:38:54 UTC
This bug was reported against an outdated version of KWin. We have made many changes since the. 
If the issue persists in newer versions can you reopen the bug report updating the version number.
Comment 3 Adam Fontenot 2023-11-03 05:14:17 UTC
I misread the request to re-open the bug and ended up recreating it, I'm going to close this version as a duplicate because the new one is clearer about what the problem is.

*** This bug has been marked as a duplicate of bug 476496 ***