https://bugs.kde.org/show_bug.cgi?id=527341
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #19 from [email protected] --- (In reply to bermudi from comment #15) > 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. I forgot when I discover this but i am sure it was here before 6.8.0. This bug actually appeared in some different behaviors. It seems work normally. Firefox and dev edition have different icons. But when refresh something (most likely .desktop entry since installing new desktop software can trigger this), firefox icons got merged. Just like this but not instantly. -- You are receiving this mail because: You are watching all bug changes.
