Open Bug 1530052 Opened 2 years ago Updated 2 months ago

WM class usage inconsistent

Categories

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

All
Linux
enhancement

Tracking

()

REOPENED
Tracking Status
firefox67 --- affected

People

(Reporter: heftig, Assigned: heftig)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

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

StartupWMClass=firefox
Icon=firefox-nightly

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 (https://firefox-flatpak.mojefedora.cz/).

See Also: → 1577056
See Also: → 1607399

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

Assignee: nobody → jan.steffens
Status: NEW → ASSIGNED

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.

Flags: needinfo?(jan.steffens)

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

Flags: needinfo?(jan.steffens)
Pushed by btara@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/360e214bf67b
Use remoting name for GDK program name and class. r=glandium
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla80
Regressions: 1652666
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla80 → ---
See Also: → 1653952
See Also: → 1650826
You need to log in before you can comment on or make changes to this bug.