After bug 1530052, the WM_CLASS of my Nightly according to xprop is:

WM_CLASS(STRING) = "Navigator", "firefox"`

I have a manually added .desktop file for my Nightly (which I originally installed by downloading the .tar.bz2 and unzipping it somewhere under my home directory), primarily so that I can point it to that installation's Nightly app icon. I thought about updating its StartupWMClass=Nightly to firefox but then I wouldn't be able to distinguish Release from Nightly.

Is there a way I can ensure that my Nightly gets its own Nightly icon, if I also have Release installed (through the package manager)?

I'm on Ubuntu 19.10 if it matters.

Hm, right, there have been changes to make different installations default to different profiles, so remoting is (normally) separated between installations and they appear to be separate applications as far as talking to them via the command line is concerned, even if their remoting name is the same.

On X11 the windows were tagged distinctly between different brandings which has now been lost, so the WM could separate Firefox release from Nightly but not release from beta or two installations of the same channel.

On Wayland, everything (but the discontinued Developer Edition) was called firefox before and after, so there never was a distinction here.

What bug 1530052 did improve was that now the same desktop file (using StartupWMClass=firefox) fits both X11 and Wayland.

I think ideally we would want not just different brandings but different installations/profiles to show up as separate apps.

You can still change the X11 program class by running firefox with --class Nightly. Is that an acceptable workaround for your desktop file? For launching via a terminal, you could do the same using a short script in PATH running exec /path/to/nightly/firefox --class Nightly "$@".

I think we need to back out bug 1530052 (or at least the class portion). The desktop files created by the set-as-default-app function still use the brand short name and their association is now lost.

Jan, I may have misunderstood your patches for bug 1530052 - I thought the intent was to use the remoting name for the WM class and use different remoting names for each channel, which I think would have solved this issue as well?

It might have (though I'm hesitant to touch the remoting name because I don't know what could break on other platforms) but as I noted in comment 2, the patches were incomplete anyway.

Bug 1530052 was backed out from autoland: https://hg.mozilla.org/integration/autoland/rev/bca48c382991c7fd778f835f2a780e3c35185fc4

based on the backout of the code that regressed this.