Bug 491398 - Header-color-using apps don't get the right colors after switching to them using Alt+Tab with tabbox UI visible
Summary: Header-color-using apps don't get the right colors after switching to them us...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: tabbox (other bugs)
Version First Reported In: 6.2.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2024-08-07 15:30 UTC by Nate Graham
Modified: 2024-11-17 18:19 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 6.3.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2024-08-07 15:30:59 UTC
SUMMARY
Git master everything built against Qt 6.7.2 on Fedora KDE 40.

If I Alt+Tab between Breeze-themed windows (e.g. Dolphin and Kate) in such a way that the tabbox UI actually appears, the windows' header areas below the SSD titlebar will fail to switch their color properly.


STEPS TO REPRODUCE:
1. Be using the default Breeze Light color scheme
2. Open Kate and Dolphin
3. Focus Kate
4. Hold down Alt
5. Press tab
6. Wait for the tabbox UI to appear
7. Press Tab enough times to go to Dolphin
8. release Alt


OBSERVED RESULT
Dolphin's toolbar background color isn't the same color as its titlebar


EXPECTED RESULT
They both match in color
Comment 1 Nate Graham 2024-08-07 15:35:26 UTC
This was caused by https://invent.kde.org/plasma/kwin/-/merge_requests/6160.
Comment 2 Vlad Zahorodnii 2024-08-07 17:04:36 UTC
The issue is caused by qtwayland synchronizing QWindow::isActive() to the wl_keyboard focus instead of using the xdg_toplevel.activated state.

FWIW The same issue can be observed on X11. I'm not sure whether it can be considered as a regression because if the task switcher handled input focus as expected, the behavior would be the same both in the Xorg session and the Wayland session.
Comment 3 Vlad Zahorodnii 2024-08-07 17:05:52 UTC
s/the behavior would be the same/the behavior would be the same from the get go/
Comment 4 Nate Graham 2024-08-07 17:06:46 UTC
Well, it wasn't happening before that commit and now it is, so I think it counts as a regression. :)  It's at least a visual regression. If we ship this, we'll end up with tons of bug reports about it, like Bug 433569, which is similarly minor but highly noticeable.
Comment 5 Nate Graham 2024-10-15 21:45:28 UTC
Appears to be fixed with today's git master!