1577056 - Profiles should use different program class (WM_CLASS) so their windows are grouped separately

Status: NEW

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

Description

[Asif Youssuff]

Been seeing this for a while , just decided to report it.

Unlike in Xorg, after opening a new Firefox profile, the application switcher does not create a new entry for the new profile. I use this to segregate my tasks via the alt tab switcher, and it is a very convenient feature in Xorg and macOS.

STR:

1. Open Firefox
2. Navigate to about:profiles
3. Create a new profile
4. Click "launch profile in new browser" below the newly created profile
5. Do alt-tab

What happens:

One Firefox icon appears.

Expected result:

Two Firefox icons appear (one for each profile opened), and the windows for each profile are grouped within each profile as separate apps.

This works on Xorg.

Comment 1

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

:yoasif, could you try to find a regression range in using for example mozregression?

Comment 2

[Kestrel]

(In reply to Asif Youssuff from comment #0)

This works on Xorg.

It doesn't work for me on Ubuntu 19.04 with X11. The program class (WM_CLASS) is used for grouping but is the same for all profiles so it is expected that they aren't grouped separately. Wayland does not use the "nightly" program class like X11 and instead uses "firefox" (Bug 1530052) but this should not affect profile grouping. You can manually set the program class on X11 with --class and on Wayland it can be done indirectly with --name.

Comment 3

[Asif Youssuff]

Kestrel, what desktop environment are you using? It works as I expect on GNOME on Ubuntu.

Comment 4

[Kestrel]

GNOME Shell groups windows to .desktop shortcuts with matching program class. If it can't find a .desktop file with matching program class then each instance is treated separately. Nightly on X11 uses nightly program class, so if you don't have a nightly.desktop file, each instance is separate. But on Wayland, Nightly uses firefox program class (Bug 1530052), so all instances (regardless of profile) group with firefox.desktop which comes with the pre-installed apt package on Ubuntu.

The solution is to give profiles unique program classes so their windows are kept separate.

Comment 5

[Asif Youssuff]

Thank you for the explanation!

Comment 6

[gudvinr]

Given that Wayland is getting more and more traction last years, this issue should be reconsidered.
I don't think, however, that manual class modification is a good idea. It would be better to implement taskbar.grouping.useprofile for Linux and possibly enable by default if user has more than one profile.

Comment 7

[andy]

A solution to setting the desktop file name presented to the wayland compositor would be great.

How chromium does this is if I launch it with chromium --user-data-dir=/path/to/profile, it will present desktopFileName as chromium (/path/to/profile) to the compositor. So I can create desktop files with

[Desktop Entry]
...
Icon=/path/to/custom-icon.svg
Exec=/usr/bin/chromium --user-data-dir=/path/to/profile %U
Name=chromium (/path/to/profile)

and get the desired program group and icon. I use this to manage isolated profiles for different use cases, clients, etc.

I don't think, however, that manual class modification is a good idea.

I'd prefer if I could just add --desktopFileName=firefox-my-custom-profile.desktop to the arguments for the most flexibility. I'm starting to use bubblewrap for more things, and if I make a desktop file that launches a bwrap'd firefox, that instance will only see the $HOME that is bound into the sandbox and the one firefox profile. One of the draws of wayland is being able to sandbox things securely, so I'm trying to benefit from that now.

Also FWIW I'm currently trying to switch from chromium to firefox and I ran into this. Mainly switching for working wayland gpu acceleration, and now working clipboard.

Comment 8

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

Firefox 124 (Bug 1859546) allows you to set desktop file name directly by MOZ_APP_REMOTINGNAME env variable, so run as:

MOZ_APP_REMOTINGNAME=firefox-my-custom-profile firefox

if your desktop file is firefox-my-custom-profile.desktop.

--desktopFileName may be another option to implement.

Comment 9

[Anatoli]

In Ubuntu 24.04 X11 Firefox snap 136.0 always groups the windows under the same icon, no matter what profile is specified, --class, etc. When running firefox with --class, xprop reports a different class compared to the main Firefox, still, the new window is grouped under the main firefox window icon. Is this a bug or a Firefox intended behavior?

Here's a .desktop launcher I create under my home dir (it's mostly a copy from the Firefox snap launcher at /var/lib/snapd/desktop/applications/firefox_firefox.desktop) which though appears as a separate launcher (with its own icon as specified) in Gnome overview (super key then type firefox), when launched, the new window is still grouped under the main window icon as one window more. Any idea what should be changed for the new window under this launcher to be placed separately in the dock?

[Desktop Entry]
X-SnapInstanceName=firefox-min
Version=1.0
Type=Application
X-SnapAppName=firefox-min
Exec=env BAMF_DESKTOP_FILE_HINT=/home/user1/.local/share/applications/firefox_firefox-min.desktop /snap/bin/firefox --new-instance --class firefox-min --name firefox-min -P Min %u
Terminal=false
Icon=/home/user1/.local/share/icons/app.png
StartupWMClass=firefox-min
StartupNotify=true
Actions=new-window;new-private-window;open-profile-manager;
Name=Firefox Min

[Desktop Action new-window]
X-SnapAppName=firefox-min
Exec=env BAMF_DESKTOP_FILE_HINT=/home/user1/.local/share/applications/firefox_firefox-min.desktop /snap/bin/firefox --new-instance --class firefox-min --name firefox-min -P Min --new-window %u
Name=New Window

[Desktop Action new-private-window]
X-SnapAppName=firefox-min
Exec=env BAMF_DESKTOP_FILE_HINT=/home/user1/.local/share/applications/firefox_firefox-min.desktop /snap/bin/firefox --new-instance --class firefox-min --name firefox-min -P Min --private-window %u
Name=New Private Window

[Desktop Action open-profile-manager]
X-SnapAppName=firefox-min
Exec=env BAMF_DESKTOP_FILE_HINT=/home/user1/.local/share/applications/firefox_firefox-min.desktop /snap/bin/firefox --new-instance --class firefox-min --name firefox-min -P Min --ProfileManager
Name=Open Profile Manager

Comment 10

[Kamil Páral]

This works for me on Fedora for a native (RPM) install, on Wayland. No idea whether Snaps require some more tweaking.

$ cat ~/.local/share/applications/firefox-work.desktop
...
Name=Firefox - Work
Exec=firefox --no-remote -P work --class 'Firefox - Work' --name 'Firefox - Work' %u
Icon=/home/username/.local/share/pixmaps/firefox-logo-work.png
StartupWMClass=Firefox - Work
...

Comment 11

[Anatoli]

(In reply to Kamil Páral from comment #10)

This works for me on Fedora for a native (RPM) install, on Wayland. No idea whether Snaps require some more tweaking.

Right, it works for a non-snap version, but a snap version (which is the default way of installing Firefox on Ubuntu even if installing via apt) is via snap, and a user can't have 2 snap firefox installations, so there's really no way to solve that from a user/admin standpoint.