Bug 492144 - Inconsistent Recently Used behavior when Alt+Tabbing after window requested attention
Summary: Inconsistent Recently Used behavior when Alt+Tabbing after window requested a...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: tabbox (show other bugs)
Version: 6.1.4
Platform: NixOS Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-08-24 20:26 UTC by André M
Modified: 2025-03-18 19:09 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description André M 2024-08-24 20:26:35 UTC
SUMMARY
When trying to Alt+Tab (task switcher) after a window draws attention, the stack gets messed up.
Switching once brings me the previously recently used application, and the one drawing attention shows as last in the queue. But, switching once again, brings the window that has drawn attention to the front (clearing the attention status), and the one I originally was goes to 3rd spot, requiring 2 +tabs to select again, even if it was the most previously focused window.

STEPS TO REPRODUCE
1. have 4 windows: 1 front (focused) window with some clickable link (e.g. Slack), 2nd next (previously focused) konsole app, then 3rd a firefox window, and 4rd some other random app (e.g. dolphin)
2. click on the link, firefox draws attention (due to the new tab)
3. alt+tab to switch windows
4. alt+tab to switch again

OBSERVED RESULT
first alt+tab brings the konsole app front; the Compact visualization shows Firefox (asking attention in task manager) last
2nd alt+tab brings the Firefox window front, Slack (previously focused) goes to 3rd place, konsole is 2nd

EXPECTED RESULT
Either:
- (preferable): windows which asks for attention consistently are brought to the 2nd place in stack (in FILO order, if more than one requested attention after last task switch), alt+tabbing switch to most recent which requested attention, originally focused window goes 2nd (as expected) and can be brought back with another alt+tab; stack list stays consistent and doesn't change between alt+tabs (unless new attention requests happened)
- (or): alt+tab window ordering isn't meddled with attention requests, user can search for it in the stack or task manager

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: NixOS unstable (currently 24.11)
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2

ADDITIONAL INFORMATION
Wayland, Ryzen 6900HX CPU, AMD Radeon 680M integrated graphics, amdgpu driver
Comment 1 André M 2024-08-24 20:31:00 UTC
Another weird way to reproduce this inconsistency:
1. On my example set of windows from OP, but Firefox is the previously focused window, konsole is 3rd
2. Click on link, Firefox draws attention
3. Alt+Tab to switch tasks: Konsole is brought front (what?!), firefox shows at end of list
4. Alt+Tab to switch again: Now firefox is next and gets focused :S, konsole goes next, Slack (original focused window) ends up 3rd again
Comment 2 André M 2024-08-28 00:26:06 UTC
Just a clarification: the "Expected result" includes the assumption that, at any point in time, Alt+Tab, then Alt+Tab again should always bring me back to the original window. This is true if no window has requested attention, and breaks due to this bug. And in the preferable behavior, that I can access the window which asked for attention last on the first Alt+Tab, the 2nd last with Alt+Tab+Tab, and so on.
Comment 3 André M 2025-03-18 00:33:00 UTC
Update: looks like the mess-up on Recently Used order is no more!
Noticed on Plasma 6.3.3, but bugfix may have gone unnoticed for longer.
The window requesting attention isn't yet "brought next" on stack, but at least Alt+tab order is always consistent, going back to the previously used window on single stroke.

So, partially fixed? Should we leave open on "bring attention requesting window to next" _feature request_, or should we close as the bug part seems fixed?
Comment 4 TraceyC 2025-03-18 19:09:12 UTC
Let's go ahead and close this report, since the original "bug" behavior is fixed. This way we can avoid confusion between the new issues.
Can you open a new report with your current system information,  and a summary of the current behavior and what you'd like to be improved?

Thanks!