1530052 - WM class usage inconsistent

Status: RESOLVED FIXED

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

Description

[Jan Alexander Steffens [:heftig]]

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

Comment 1

[Jan Alexander Steffens [:heftig]]

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

Comment 2

[Jan Alexander Steffens [:heftig]]

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.

Comment 3

[Jan Alexander Steffens [:heftig]]

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

Comment 4

[Martin Stránský [:stransky] (ni? me)]

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

Comment 5

[Jan Alexander Steffens [:heftig]]

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.

Comment 6

[Mike Hommey [:glandium]]

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

Comment 7

[Mike Hommey [:glandium]]

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

Comment 8

[Laurențiu Nicola]

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?

Comment 9

[Laurențiu Nicola]

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

Comment 10

[Martin Stránský [:stransky] (ni? me)]

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

Comment 11

[Asif Youssuff]

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

Comment 12

[Robert Mader [:rmader]]

(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

Comment 13

[Laurențiu Nicola]

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

Comment 14

[Argy Megalios]

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.

Comment 15

[Jan Alexander Steffens [:heftig]]

Attachment: 0001-Use-remoting-name-for-GDK-application-names.patch

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/

Comment 16

[Martin Stránský [:stransky] (ni? me)]

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

Comment 17

[Jan Alexander Steffens [:heftig]]

Attachment: Bug 1530052 - Use remoting name for GDK program name and class. r?glandium

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 19

[Jan Alexander Steffens [:heftig]]

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

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/360e214bf67b
Use remoting name for GDK program name and class. r=glandium

Comment 21

[Dorel Luca [:dluca]]

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

Comment 22

[Razvan Maries]

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

Comment 23

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 24

[Mike Kaply [:mkaply]]

Backed out as requested on Riot

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

Comment 25

[Mike Hommey [:glandium]]

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

Comment 26

[Martin Stránský [:stransky] (ni? me)]

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

Comment 27

[Emilio Cobos Álvarez (:emilio)]

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?

Comment 28

[Jan Alexander Steffens [:heftig]]

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.

Comment 29

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 34

[Jan Alexander Steffens [:heftig]]

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

Comment 35

[movisivi]

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.

Comment 36

[Emilio Cobos Álvarez (:emilio)]

This should be landable now after bug 1752418.

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2d57471cb4b8
Use remoting name for GDK program name and class. r=glandium

Comment 38

[Norisz Fay [:noriszfay]]

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'

Comment 39

[Jan Alexander Steffens [:heftig]]

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

Comment 40

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4c78c3f1e3e9
Use remoting name for GDK program name and class. r=glandium

Comment 41

[Cristian Tuns]

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

Comment 42

[Bob Hood [:bhood]]

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

Comment 43

[Bob Hood [:bhood]]

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