User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0

Steps to reproduce:

I'm using the Snap packages provided by default on Ubuntu 24.04.

Actual results:

Recently, Firefox windows cannot match their launcher in Cairo-Dock (https://github.com/Cairo-Dock/cairo-dock-core).

The problem seems to be caused by the desktop file providing the following key:

StartupWMClass=firefox-release

which does not match the class / app-id reported by Firefox (which is simply "firefox" both on Wayland and X11)

Expected results:

StartupWMClass key actually matches the app-id / class of Firefox.

A similar bug was reported (and solved) for the Flatpak version: https://bugzilla.mozilla.org/show_bug.cgi?id=1770636

The Bugbug bot thinks this bug should belong to the 'Firefox Build System::Third Party Packaging' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

The severity field is not set for this bug.
:gerard-majax, could you have a look please?

For more information, please visit BugBot documentation.

As much as I understand this was done on purpose by Snap packagers, I'm not sure if Sebastian knows more

(In reply to :gerard-majax from comment #3)

As much as I understand this was done on purpose by Snap packagers, I'm not sure if Sebastian knows more

I'm not aware of those details but poking it seems things changed upstream in https://bugzilla.mozilla.org/show_bug.cgi?id=1901703

The bug references to https://hg.mozilla.org/integration/autoland/rev/52edc40e4c0d

which includes

"StartupWMClass": "{}-{}".format(appname, branchname),

(edit previous post), I've found https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2045820 , the -branchname seems needed for beta but maybe the release case is wrong?

https://github.com/canonical/firefox-snap/blob/13aca964eaa75e7f4f194ac8e4465869e8e609c6/snapcraft.yaml#L423

Precisely on the correct branch it's derivated from https://github.com/canonical/firefox-snap/blob/066833025ed2a4ef542eb2add16e197e2470fcaa/snapcraft.yaml#L412 and the code mentionned in comment 4.

Cairo Dock handled it 3 weeks ago in https://github.com/Cairo-Dock/cairo-dock-core/commit/032472070e3a5bf1a8aa8167e2219da25c7ab6fd, they even mention it directly in the comments in https://github.com/Cairo-Dock/cairo-dock-core/blame/9f9421ee507515d5fe7241d28957be8772ee1161/src/gldit/cairo-dock-class-manager.c#L233-L236C6:

--->
* Concrete example: Firefox Snap version 131 on Ubuntu 24.04, with
* app-id / class: firefox,
* file name: firefox_firefox.desktop (matched in _search_desktop_file()),
* and StartupWMClass=firefox-release
<---

So just waiting a new release would fix the bug as described I suppose.

On the other hand...

StartupWMClass If specified, it is known that the application will map at least one window with the given string as its WM class or WM name hint

says the specification https://specifications.freedesktop.org/desktop-entry-spec/latest/recognized-keys.html so one must conclude

•        "StartupWMClass": "{}-{}".format(appname, branchname),
  

in https://hg.mozilla.org/integration/autoland/rev/52edc40e4c0d is simply violating the standard and we must revert that bit and frustate the Cairo Dock maintainer again by doing so.

Set release status flags based on info from the regressing bug 1901703

Set release status flags based on info from the regressing bug 1901703

Hi Nathan, are we able to get this landed for the next cycle? Thanks!

Hi Nikki, the patch is ready as in the linked Phabricator merge request, I just need someone to merge it.

https://hg.mozilla.org/mozilla-central/rev/aeacbe163ade