AFAICT, handling of the X window class seems to be inconsistent:

toolkit/mozapps/installer/linux/rpm/mozilla.desktop sets StartupWMClass=@MOZ_APP_REMOTINGNAME@, which is "firefox".

The X11 code sets the window class itself (via gtk_window_set_wmclass or XSetClassHint) and uses the brandShortName (via gdk_set_program_class/gdk_get_program_class), which is "Nightly".

GTK wants to use the prgname ("Firefox", from MOZ_APP_BASENAME) for the name of the class instance, but the code overrides it with various strings like "Toplevel", "Navigator", "Dialog" and "Popup".

The Wayland code seems to leave GTK's choices undisturbed, so the window's app-id is the prgname, "Firefox".

I'm using a desktop file with StartupWMClass=Nightly right now, which works on X11 but not on Wayland.

The patch used by Debian fixes the class set on X windows.

However, it's insufficient for the GTK Wayland backend, which prefers to use the prgname.

Ah, there's another patch in Debian for the latter issue. (The ToLowerCase left in place by the patch can probably be removed.)

Sorry to being dumb here but what practical issues does this cause? We don't have any such patch at Fedora and I don't see any issues with that, no reports...

It doesn't matter with release Firefox as everything is named "Firefox" anyway:

• remoting name: firefox
• class of X windows: Firefox (matched by StartupWMClass=Firefox, or, heuristically, firefox.desktop)
• app ID of Wayland windows: firefox (matched by firefox.desktop)

But on Nightly the situation is different:

• remoting name: firefox
• class of X windows: Nightly (matched by StartupWMClass=Nightly)
• app ID of Wayland windows: firefox (cannot be distinguished from release)

On Arch Linux, I set MOZ_APP_REMOTINGNAME=firefoxnightly for the firefox-nightly package.
This has the benefit of separating release and nightly into two separate apps that won't attempt to communicate.

With the patches above setting prgname and window_class to the remoting name, the shell can properly track the windows:

• remoting name: firefoxnightly
• class of X windows: firefoxnightly (matched by StartupWMClass=firefoxnightly)
• app ID of Wayland windows: firefoxnightly (matched by StartupWMClass=firefoxnightly)

In addition, the desktop file template used by the RPM packager (toolkit/mozapps/installer/linux/rpm/mozilla.desktop) uses StartupWMClass=@MOZ_APP_REMOTINGNAME@ already. Though I'm not sure who uses this.

Yes, as I mentioned at some point on irc, this needs to be reevaluated in the light of the recent changes wrt remoting. But to answer Martin's question, the main problem is Gnome recognizing that the .desktop-launched app started up (startup notification).

BTW, we should also have a in-mozilla-central .desktop file, per bug 1323666 comment 12.

Might this be the reason why Wayland Firefox / Gnome is missing an icon, can't be pinned, and has every window shown as a different app?

Here is a workaround for anyone else affected. Edit the most recent of ~/.local/share/applications/userapp-Nightly-*.desktop and add

StartupWMClass=firefox
Icon=firefox-nightly

IMHO all those issues can be solved if the nightly is distributed as flatpak/snap self contained packages. I can't say for snap but we have good feedback about our experimental nightly flatpak package (https://firefox-flatpak.mojefedora.cz/).

(In reply to Laurențiu Nicola from comment #8)

Might this be the reason why Wayland Firefox / Gnome is missing an icon, can't be pinned, and has every window shown as a different app?

I ran into this in Debian, because they ship Firefox ESR, and the fact that each window is shown as a different app is extremely annoying -- I thought it was a mutter bug. It is not obvious to me that I would have to "install" a .desktop file manually, (especially when Nightly is distributed as a tarball) to make window grouping work in the alt-tab switcher in GNOME.

(In reply to Mike Hommey [:glandium] from comment #6)

But to answer Martin's question, the main problem is Gnome recognizing that the .desktop-launched app started up (startup notification).

This should have been fixed now with bug 726479

(In reply to robert.mader from comment #12)

(In reply to Mike Hommey [:glandium] from comment #6)

But to answer Martin's question, the main problem is Gnome recognizing that the .desktop-launched app started up (startup notification).

This should have been fixed now with bug 726479

Not for me on Arch Linux / Gnome Wayland. The startup notification stuff seems to work, but it has no icon (Icon=firefox-nightly fixes that) and I can't add the application as favorite (StartupWMClass=firefox seems to fix it).

As above, still affected by this bug on Arch + Gnome + Wayland. The wmclass for both Nightly and Release under wayland is firefox and the Release icon always shows up in the sidebar when I launch either version under wayland (presumably it is preferred because it's firefox.desktop?). Setting StartupWMClass=firefox in Nightly only works if the Release .desktop file is deleted.

My firefox and firefox-nightly builds for Arch Linux still use the attached patch (and set MOZ_REMOTING_NAME to firefox respectively firefoxnightly) to fix this problem.

Debian still carries two similar patches:

https://sources.debian.org/patches/firefox/77.0-1/debian-hacks/Set-program-name-from-the-remoting-name.patch/

https://sources.debian.org/patches/firefox/77.0-1/debian-hacks/Use-remoting-name-for-call-to-gdk_set_program_class.patch/

Jan, please submit the patch via phabricator and ask Mike (glandium) for review.
Thanks.

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:heftig, could you have a look please?
For more information, please visit auto_nag documentation.

Whoops, sorry. Didn't notice comments were made and the patch was accepted.

https://hg.mozilla.org/mozilla-central/rev/360e214bf67b

Backed out as requested on Riot: https://hg.mozilla.org/integration/autoland/rev/bca48c382991c7fd778f835f2a780e3c35185fc4

Backout merged: https://hg.mozilla.org/mozilla-central/rev/bca48c382991

Backed out as requested on Riot

Can someone provide context as to why this change didn't stick?

https://matrix.to/#/!lrZtdjyLpBmoKbMdyx:mozilla.org/$xNiAgQEX5rGf5RKOYajAvAeyFRE47RRjd1zlhcOxh18?via=mozilla.org&via=matrix.org&via=igalia.com and following.

Let's see, there's a try for D80371:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=89b7853d726644cdd1971b9ce7b252f23e799196

So what's the state of this? Right now Nightly windows on Wayland can't be differentiated from release... Would this fix it or is that a separate issue?

IIRC (I can no longer access the Matrix log above) with just D80371 it actually gets worse. Everything is then just firefox, for both X11 and Wayland, which is certainly a win in consistency (the remoting name is already being used for D-Bus) but no longer permits differentiating nightly and release on X11, either.

I think this patch would need to be paired with a separate remoting name for each channel to avoid that regression. However, I have no idea how that would affect the other platforms.

Having a generated remoting name for each installation (similar to how profiles are associated with installations) would be ideal. But that would have to be a follow-up, assuming it's even possible.

I think the patch needs to be reworked to include correct name as per https://bugzilla.mozilla.org/show_bug.cgi?id=1530052#c5
We may also use different names for remote which should be doable as we use DBus only now.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #29)

I think the patch needs to be reworked to include correct name as per https://bugzilla.mozilla.org/show_bug.cgi?id=1530052#c5
We may also use different names for remote which should be doable as we use DBus only now.

Just to be clear, which setup of D-Bus name / X window class / app ID do you mean?

FINALLY found a solution that separates Nightly and Firefox in Fedora 35. Its all in the .desktop file you make for Nightly. Here's mine

[Desktop Entry]
Version=1.0
Name=Firefox Nightly
Exec=env MOZ_ENABLE_WAYLAND=1 /home/mjbrm/firefox/firefox-bin --name=firefox-nightly -P default-nightly %u
Icon=/home/mjbrm/firefox/browser/chrome/icons/default/default128.png
Terminal=false
Type=Application
MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;x-scheme-handler/http;x-scheme-handler/https;
Categories=Network;WebBrowser;
Keywords=web;browser;internet;
StartupNotify=true
StartupWMClass=firefox-nightly

Note the --name=firefox-nightly in Exec= and StartupWMClass=firefox-nightly matching. This was the missing piece! Now I can run Nightly under Wayland with the correct name and icon. Hope this helps others. I know it did for me. Found this at https://arongriffis.com/2020-03-28-firefox-nightly.

--name=firefox-nightly sets wmclass so GNOME associates the icon in the dock with the running windows, and keeps it separate from the Fedora-supplied stable Firefox. This must match the setting for StartupWMClass.

This should be landable now after bug 1752418.

Backed out for causing build bustages

Backout link

Push with failures

Failure log

Failure line: /builds/worker/checkouts/gecko/widget/gtk/nsAppShell.cpp:263:39: error: member access into incomplete type 'const mozilla::XREAppData'

Emilio, nsAppShell.cpp needs an additional #include "mozilla/XREAppData.h", but it seems I can no longer touch D80371.

https://hg.mozilla.org/mozilla-central/rev/4c78c3f1e3e9

:heftig, can you give us some input on the referenced regression? This "consistency" change appears to have broken some location mechanisms in Linux.

Ah, nevermind. Seems you did already, and I missed it. Sorry.