https://bugs.kde.org/show_bug.cgi?id=527341
bermudi <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #15 from bermudi <[email protected]> --- Confirming on EndeavourOS, Plasma 6.8.1 (kwin 6.8.0), Wayland, both browsers installed from the Arch repos (firefox 158.0.1-1, firefox-developer-edition 159.0b5-1). I traced the mechanism through the v6.8.0/v6.8.1 released sources; window values below are from my live system via KWin scripting (they corroborate the kwindowprop output in comment #2): 1. Both Arch packages install their actual binary as "firefox" (only the directory differs: /usr/lib/firefox/firefox vs /usr/lib/firefox-developer-edition/firefox). KWin derives a fallback resource name from the client executable's basename (WaylandWindow::updateResourceName(), kwin src/waylandwindow.cpp:160-168, via /proc/<pid>/exe) and advertises it alongside the appId over the plasma window management protocol (kwin src/window.cpp:1769-1772). Live values for the Developer Edition window: desktopFile = "firefox-developer-edition", resourceClass = "firefox-developer-edition", resourceName = "firefox". Regular Firefox reports "firefox" for all three. 2. libtaskmanager feeds that resourceName into the desktop file resolver first, as the xWindowsWMClassName argument (libtaskmanager/waylandtasksmodel.cpp:821 in plasma-workspace 6.8.1): windowUrlFromMetadata(appId, pid, resourceName). 3. serviceFromMetadata() (libtaskmanager/tasktools.cpp:229-243) matches StartupWMClass == xWindowsWMClassName (= resourceName) *before* it ever tries the appId. firefox.desktop declares StartupWMClass=firefox, which matches the Developer Edition window's resourceName "firefox", so the window resolves to firefox.desktop and the correct appId "firefox-developer-edition" is never consulted. 4. appsMatch() (libtaskmanager/tasktools.cpp:503) groups windows that resolved to the same launcher URL, so the Developer Edition window merges under the regular Firefox button. This also explains why renaming the Developer Edition desktop file cannot fix the Arch package (comments #9-12): the wrong match happens inside firefox.desktop; the Developer Edition desktop file is never reached. Workaround, verified on 6.8.1: shadow firefox.desktop with a local copy that differs only by the removed StartupWMClass line: cp /usr/share/applications/firefox.desktop ~/.local/share/applications/firefox.desktop sed -i '/^StartupWMClass=/d' ~/.local/share/applications/firefox.desktop kbuildsycoca6 --noincremental then restart plasmashell. With firefox.desktop no longer declaring StartupWMClass=firefox, the Developer Edition window misses at the resourceName stage and then matches its own StartupWMClass=firefox-developer-edition via the appId stage (its desktop file is untouched); regular Firefox misses both StartupWMClass stages and still resolves to firefox.desktop via DesktopEntryName == appId. The Developer Edition then gets its own task button with the correct blue icon; regular Firefox is unaffected. Two things I have *not* established: - What change exposed this in 6.8: the kwin fallback (waylandwindow.cpp is byte-identical between v6.7.0 and v6.8.0), the resourceName hand-off (waylandtasksmodel.cpp:825 in v6.7.0) and the StartupWMClass-first resolution order (tasktools.cpp in v6.7.0) all already exist in 6.7, so the collision should have been possible before -- something else must have changed to expose it. - Why the official Mozilla build behaves differently from the Arch build on the same system (comment #8). Speculation, untested: the same resourceName/StartupWMClass collision could also explain bug 527444 (Chromium PWAs grouped under Chromium: a PWA window would carry the browser binary's basename as resourceName, matching the browser's own StartupWMClass), but I have not verified that case. -- You are receiving this mail because: You are watching all bug changes.
