Hi, Claude helped me write this bug report, suggested I posted it here:
Distribution: Linux Mint (Cinnamon) Package version (cinnamon --version): Cinnamon 6.6.9 Graphics hardware in use: No response Frequency: Always (after the first launch following a Cinnamon restart)
Bug description
Two different Gecko-based web browsers, installed as Flatpaks (Zen Browser: app.zen_browser.zen, and Floorp: presumably one.ablaze.floorp), end up showing the same icon in the panel's window list applet — specifically, whichever of the two was tracked first after the last Cinnamon restart "wins," and the other browser's window is shown with that same (wrong) icon.
Both apps have correct and distinct .desktop entries with correct Icon= and StartupWMClass= values, and the icon files exist on disk in the standard hicolor theme location. So this is not a missing-icon or icon-cache problem — it's a wrong-app-association problem.
Root cause hypothesis (with evidence)
xprop WM_CLASS on each running browser window gives:
Zen: WM_CLASS(STRING) = "Navigator", "zen"
Floorp: WM_CLASS(STRING) = "Navigator", "floorp"
The class (2nd string, res_class) correctly differs between the two apps and correctly matches each app's StartupWMClass in its .desktop file. However, the instance (1st string, res_name) is identical for both — "Navigator" — which is a legacy value that Gecko-based browsers have set for WM_CLASS instance since the Netscape era, for backward compatibility. This value is not user-configurable and is shared by every Gecko-based browser (Firefox, Zen, Floorp, LibreWolf, etc.).
This strongly suggests that somewhere in Cinnamon's app-matching/caching logic (Cinnamon.WindowTracker, and/or the window-to-app association used by the window-list applets), matching or caching keys off the WM_CLASS instance (res_name) instead of, or in addition to, the class (res_class). Since both apps share the same instance string "Navigator", the second Gecko-based Flatpak app launched after a Cinnamon restart gets associated with whichever app/icon was already cached for that instance string, rather than being matched via its own .desktop/StartupWMClass.
This is consistent with the partial fix in #9951 ("moving the match against the info from the .flatpak-info file further down the line"), which suggests the association logic tries several matching strategies in sequence and one of the earlier/fallback strategies is keying off the wrong WM_CLASS field for Flatpak apps.
Steps to reproduce
Install two different Gecko-based browsers as Flatpaks (e.g. Zen Browser and Floorp) from Flathub.
Restart Cinnamon (Right-click panel/desktop → Troubleshoot → Restart Cinnamon), or log in fresh. At this point, whichever browser is opened first shows the correct icon in the panel.
Open Zen Browser. Confirm its icon is correct in the panel/window list.
Close Zen Browser.
Open Floorp.
Observe: Floorp's window in the panel/window list shows Zen Browser's icon instead of Floorp's own icon (or a generic placeholder icon, depending on order/timing).
Restarting Cinnamon again temporarily "fixes" the icon (forces re-matching), until the sequence is repeated.
Expected behaviour
Each Flatpak Gecko-based browser should always show its own distinct icon in the panel/window list, regardless of launch order or what other Gecko-based Flatpak apps have been run since the last Cinnamon restart. App matching should not rely on the WM_CLASS instance (res_name) alone, since this value is not guaranteed to be unique across different applications built on the same toolkit/engine.
Additional information
.desktop file for Zen (from /var/lib/flatpak/exports/share/applications/app.zen_browser.zen.desktop) includes a correct StartupWMClass=zen line.
Icon files for both apps exist correctly under /var/lib/flatpak/exports/share/icons/hicolor/.../apps/.
A Cinnamon restart reliably resolves the issue temporarily, which points to an app-association cache issue rather than a missing icon/theme issue.
This appears related to, but distinct from, #9951, #10401, and #12307, which describe similar wrong/missing-icon symptoms for Flatpak apps but do not identify the shared WM_CLASS instance ("Navigator") as the specific collision mechanism.
Hi, Claude helped me write this bug report, suggested I posted it here:
Distribution: Linux Mint (Cinnamon) Package version (cinnamon --version): Cinnamon 6.6.9 Graphics hardware in use: No response Frequency: Always (after the first launch following a Cinnamon restart)
Bug description
Two different Gecko-based web browsers, installed as Flatpaks (Zen Browser: app.zen_browser.zen, and Floorp: presumably one.ablaze.floorp), end up showing the same icon in the panel's window list applet — specifically, whichever of the two was tracked first after the last Cinnamon restart "wins," and the other browser's window is shown with that same (wrong) icon.
Both apps have correct and distinct .desktop entries with correct Icon= and StartupWMClass= values, and the icon files exist on disk in the standard hicolor theme location. So this is not a missing-icon or icon-cache problem — it's a wrong-app-association problem.
Root cause hypothesis (with evidence)
xprop WM_CLASS on each running browser window gives:
Zen: WM_CLASS(STRING) = "Navigator", "zen"
Floorp: WM_CLASS(STRING) = "Navigator", "floorp"
The class (2nd string, res_class) correctly differs between the two apps and correctly matches each app's StartupWMClass in its .desktop file. However, the instance (1st string, res_name) is identical for both — "Navigator" — which is a legacy value that Gecko-based browsers have set for WM_CLASS instance since the Netscape era, for backward compatibility. This value is not user-configurable and is shared by every Gecko-based browser (Firefox, Zen, Floorp, LibreWolf, etc.).
This strongly suggests that somewhere in Cinnamon's app-matching/caching logic (Cinnamon.WindowTracker, and/or the window-to-app association used by the window-list applets), matching or caching keys off the WM_CLASS instance (res_name) instead of, or in addition to, the class (res_class). Since both apps share the same instance string "Navigator", the second Gecko-based Flatpak app launched after a Cinnamon restart gets associated with whichever app/icon was already cached for that instance string, rather than being matched via its own .desktop/StartupWMClass.
This is consistent with the partial fix in #9951 ("moving the match against the info from the .flatpak-info file further down the line"), which suggests the association logic tries several matching strategies in sequence and one of the earlier/fallback strategies is keying off the wrong WM_CLASS field for Flatpak apps.
Steps to reproduce
Install two different Gecko-based browsers as Flatpaks (e.g. Zen Browser and Floorp) from Flathub.
Restart Cinnamon (Right-click panel/desktop → Troubleshoot → Restart Cinnamon), or log in fresh. At this point, whichever browser is opened first shows the correct icon in the panel.
Open Zen Browser. Confirm its icon is correct in the panel/window list.
Close Zen Browser.
Open Floorp.
Observe: Floorp's window in the panel/window list shows Zen Browser's icon instead of Floorp's own icon (or a generic placeholder icon, depending on order/timing).
Restarting Cinnamon again temporarily "fixes" the icon (forces re-matching), until the sequence is repeated.
Expected behaviour
Each Flatpak Gecko-based browser should always show its own distinct icon in the panel/window list, regardless of launch order or what other Gecko-based Flatpak apps have been run since the last Cinnamon restart. App matching should not rely on the WM_CLASS instance (res_name) alone, since this value is not guaranteed to be unique across different applications built on the same toolkit/engine.
Additional information
.desktop file for Zen (from /var/lib/flatpak/exports/share/applications/app.zen_browser.zen.desktop) includes a correct StartupWMClass=zen line.
Icon files for both apps exist correctly under /var/lib/flatpak/exports/share/icons/hicolor/.../apps/.
A Cinnamon restart reliably resolves the issue temporarily, which points to an app-association cache issue rather than a missing icon/theme issue.
This appears related to, but distinct from, #9951, #10401, and #12307, which describe similar wrong/missing-icon symptoms for Flatpak apps but do not identify the shared WM_CLASS instance ("Navigator") as the specific collision mechanism.