Open Bug 1530052 Opened 10 months ago Updated 3 months ago

WM class usage inconsistent


(Core :: Widget: Gtk, enhancement, P3)




Tracking Status
firefox67 --- affected


(Reporter: heftig, Unassigned)


(Blocks 1 open bug)


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.

Flags: needinfo?(mh+mozilla)

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...

Flags: needinfo?(jan.steffens)

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.

Flags: needinfo?(jan.steffens)

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).

Flags: needinfo?(mh+mozilla)

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


Priority: -- → P3

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 (

See Also: → 1577056
You need to log in before you can comment on or make changes to this bug.