Bug 492144

Summary:	Inconsistent Recently Used behavior when Alt+Tabbing after window requested attention
Product:	[Plasma] kwin	Reporter:	André M <andre.vmatos>
Component:	tabbox	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	andre.vmatos, kdedev, nate
Priority:	NOR
Version First Reported In:	6.1.4
Target Milestone:	---
Platform:	NixOS
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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!

Comment 5 André M 2025-09-15 22:08:15 UTC

Bug returned on recent versions, same behavior as before; running 6.4.5 now

Comment 6 TraceyC 2025-09-22 19:32:38 UTC

I'm not able to reproduce this with git-master, following the steps to reproduce in the original message. I used Discord in place of Slack in step 1.

3. alt+tab to switch windows - Switched to Discord where I had clicked the link (not Konsole)
4. alt+tab to switch again -  Switched to Firefox since it had focus before Discord

Could you provide us a screen recording of your testing steps, start to finish, to make sure we're doing the same thing?

Comment 7 Bug Janitor Service 2025-10-07 03:46:53 UTC

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

Comment 8 Bug Janitor Service 2025-10-22 03:47:08 UTC

🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.