https://bugs.kde.org/show_bug.cgi?id=447845
omusgoso <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |om --- Comment #30 from omusgoso <[email protected]> --- I tested this directly on two separate distros to isolate the cause, one running openSUSE Tumbleweed with KDE Plasma 6.7.3, the other running Fedora Linux 44 with the COSMIC desktop, both on Wayland, both running the same browser (Helium, a Chromium-based browser) with the identical PWA (SoundCloud) installed the same way. On the openSUSE/Plasma 6 machine, the PWA's taskbar icon merges into the main browser's icon within about a second of opening. On the Fedora/COSMIC machine, under otherwise equivalent conditions, the PWA correctly keeps its own separate taskbar icon. Since both machines produced an identical .desktop file (StartupWMClass=crx_<app-id>, same --app-id flag) and both run the browser as a single native-Wayland process (confirmed via pgrep -af helium, no separate process spawned for the PWA on either system), this points to the difference being in how each desktop's taskbar widget resolves window identity, not in Chromium/Helium itself, and not in AppImage vs. native packaging (I tested with the official AppImage on openSUSE and the vendor's native .rpm repo package on Fedora). I don't have visibility into COSMIC's internal implementation to say definitively why it handles this correctly, but it's worth noting COSMIC's own taskbar (cosmic-app-list) and its ecosystem's PWA tooling are aware of this general class of bug, a COSMIC-specific web-app packaging tool has an open issue about ensuring StartupWMClass correctly matches the running window's class for taskbar grouping (https://github.com/olafkfreund/cosmic-ext-web-apps/issues/46), suggesting the COSMIC community has treated this matching logic as something to get right deliberately. Given that COSMIC is a from-scratch Wayland compositor and shell built independently of KWin (using Smithay rather than KWin's codebase, see https://wiki.archlinux.org/title/COSMIC), it's plausible its cosmic-app-list implements window-to-launcher matching more strictly or with better fallback handling than KWin currently does, rather than relying on whatever mechanism is failing here. I'm raising this as a data point for comparison, not a suggested fix, since I don't know KWin's internals well enough to say what specifically differs. -- You are receiving this mail because: You are watching all bug changes.
