1747722 - Arguments `--class` and `--name` (to set the program class) are used only once per running profile

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Filip Štamcar]

Problem Description

Arguments --class (on X11) and --name (on Wayland) can be used to set the program class to (un)group different Firefox windows. This can be used to separate different Firefox profiles (create a .desktop file for each profile and launch Firefox with a different program class), in which case it works as expected (every profile gets its own program class).

However, doing this in the same profile will not work, as the program class will still be set to the first value even after subsequential runs. This is a problem for me, because I'm creating a project that allows users to install PWAs, so because of this Firefox behavior, all windows from the same profile will be merged. This happens both on X11 and Wayland.

I think this happens because all Firefox windows in the same profile, even if launched using multiple subsequential commands, will still share the same processes, causing them to have the same program class as the first one.

Expected Behavior

A new program class should be set for every window that is launched with a new command (with --class and --name arguments), even if they are using the same profile.

For example, running

$ firefox --profile profiles/example --class AAA --name AAA &
$ firefox --profile profiles/example --class BBB --name BBB &

should open two windows, each with a different program class.

Steps to Reproduce

To show the problem when using the same profile:

1. Close all Firefox windows.
2. Using terminal, run firefox --profile profiles/first --class AAA --name AAA.
3. Using xprop or similar tools, observe that the program class is correctly set to AAA (WM_CLASS(STRING) = "Navigator", "AAA").
4. Using terminal (without closing the first window), run firefox --profile profiles/first --class BBB --name BBB.
5. Using xprop or similar tools, observe that the new window still incorrectly uses the original program class.

To show using multiple profiles works:

1. Close all Firefox windows.
2. Using terminal, run firefox --profile profiles/first --class AAA --name AAA.
3. Using xprop or similar tools, observe that the program class is correctly set to AAA (WM_CLASS(STRING) = "Navigator", "AAA").
4. Using terminal (without closing the first window), run firefox --profile profiles/second --class BBB --name BBB.
5. Using xprop or similar tools, observe that the new window correctly uses BBB as the program class (WM_CLASS(STRING) = "Navigator", "BBB").

Comment 1

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

The severity field is not set for this bug.
:enndeakin, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

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

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Filip Štamcar]

I have made some research on how Firefox currently handles setting class hints for windows. Arguments --class and --name are handled directly by GDK, and it's probably intentional that only one value is set for all windows in a single program instance. However, Firefox also already uses XSetClassHint to set additional class hints per window. The value of res_class is obtained using gdk_get_program_class (which is the same for all windows in the program), and the value of res_name is obtained by parsing window attribute windowtype.

This shows that it is already kinda possible to (partially) set window class hints from the chrome/JS (by setting the correct attribute at the correct time). However, for my use case (ungrouping different PWA windows), this does not fully work. The first problem is that we can only change res_name while res_class is still tied to gdk_get_program_class. The second problem is that changing the windowtype attribute to an arbitrary value (in my case, the ULID of the PWA) can break Firefox code expecting the windowtype to be navigator:browser.

I propose adding two new attributes to the window's html element, windowclass and windowname, to allow directly controlling the window's res_class and res_name from the chrome/JS code. And in case these attributes are not set (which is probably always except in a custom code such as in my project), the current behavior of determining res_class and res_name is preserved.

I have already made a patch for this and will attach it soon. With this patch, setting windowclass and windowname attributes at the moment a new window is created (which is around here in my code; as you can see, I already use something similar to set the window icon), correctly assigns two taskbar entries for two PWAs, on default Ubuntu GNOME, both on Xorg and Wayland. So, I think the patch works, but it probably still needs some review and potential code quality improvements.

I know this patch does not actually directly address this bug (--class and --name arguments still behave as they did), but, at least for my use case, it works fine and probably even better than messing with arguments. Although this might be quite an obscure feature/option that probably won't be used in normal Firefox code, it would be very nice for me if it can get accepted, because I think it is the only way how I can fix that issue in my project without maintaining own Firefox fork with this patch.

Comment 4

[Filip Štamcar]

Attachment: Bug 1747722 - Allow changing window class hints using attributes. r=emilio,stransky

This patch adds two new attributes to the window's html element,
windowclass and windowname, to allow directly controlling the
window's class hints on Xorg/Wayland (res_class and res_name)
from the chrome/JS code. When they are set, values are used as class
hints for their window. When they are not set, the current behavior
of determining res_class and res_name (using gdk_get_program_class
for res_class and parsing windowtype for res_name) is preserved.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/790ce057b9af
Allow changing window class hints using attributes. r=emilio,stransky

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/790ce057b9af