https://bugs.kde.org/show_bug.cgi?id=527431
pep <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from pep <[email protected]> --- I can reproduce this on openSUSE Tumbleweed and have narrowed it down to KWin replacing the app_id of Flatpak Chromium PWA windows. SOFTWARE - Plasma 6.8.1, KWin 6.8.1 - kwin6 6.8.0 was installed on 2026-10-18 (via zypper history) - Flatpak 1.18.4 - org.chromium.Chromium 156.0.8078.47 (Flathub, system installation) - Wayland session WHAT CHROMIUM SENDS vs WHAT KWIN REPORTS 1. Closed all Chromium instances (flatpak ps empty). 2. Launched a PWA with Wayland protocol logging: flatpak run --env=WAYLAND_DEBUG=1 --command=/app/bin/chromium org.chromium.Chromium \ --profile-directory=Default --app-id=fmpnliohjhemenmnlpbfagaolkdacoja 3. The client log shows exactly one: set_app_id("chrome-fmpnliohjhemenmnlpbfagaolkdacoja-Default") 4. But KWin (queryWindowInfo) reports for that same window: desktopFile: org.chromium.Chromium resourceClass: org.chromium.Chromium resourceName: (empty) So Chromium sends the correct per-app ID, matching the PWA's .desktop file, but KWin replaces it with the Flatpak sandbox app ID. That makes every PWA indistinguishable from the browser itself, which explains the disabled "Pin to Task Manager" and the duplicate icon when launching a pinned PWA. Window rules matching on window class cannot help, since all PWA windows end up with the same class. This looks related to the KWin change in 6.8.0 "Xdgshellwindow: work around wrong app IDs in flatpak apps" (kwin commit 389d2360236e32ea60a7d664090f79d5294fae1b), which presumably overrides app IDs that don't match the security-context app ID. Chromium PWA app IDs (chrome-<id>-<profile>) are legitimate but never carry the org.chromium.Chromium prefix. This seems to be a different layer from the mechanism described in bug 527341 comment 15 (StartupWMClass matched against resourceName in libtaskmanager): in this Flatpak case resourceName is empty, and the app ID is already wrong at the KWin level, before libtaskmanager is involved. Note also the contrast with bug 527444: with native (non-Flatpak) Chromium, KWin reports the correct desktopFileName. WORKAROUND (confirmed working) Force Chromium onto XWayland, where the PWA identity travels in WM_CLASS: - add "--ozone-platform=x11" to ~/.var/app/org.chromium.Chromium/config/chromium-flags.conf - set StartupWMClass=crx_<app-id> in each PWA .desktop file Under X11, KWin reports resourceName: crx_fmpnliohjhemenmnlpbfagaolkdacoja and the window associates correctly with its pinned launcher. -- You are receiving this mail because: You are watching all bug changes.
