Open Bug 849571 Opened 7 years ago Updated 1 year ago

WM_CLASS changes after a restart (gnome-shell)

Categories

(Firefox :: Shell Integration, defect, major)

21 Branch
x86_64
Linux
defect
Not set
major

Tracking

()

People

(Reporter: micmon, Unassigned)

References

Details

Background: I use Firefox in GNOME 3. Running one instance works fine, but running a second one (for example stable and aurora, or two separate profiles) is tricky: in order to not break the window management in gnome-shell, you need to create a second .desktop file and use --class=foo to match WM_CLASS and .desktop file name.

This works fine as long as the browser does not restart, which unfortunately happens sooner or later:
- after enabling/disabling some extensions
- after applying updates
- after a crash

When such a restart is triggered, the WM_CLASS is the default one ("Firefox"), it does no longer set the WM_CLASS you requested using --class.

Is there a way to apply this class also after restarts? This would solve the problem I think.

Anyway I think it would be helpful to not use "Firefox" for all Firefox build channels and also use different executable names for each one.
See Also: → 1151753
Duplicate of this bug: 1308719
I think this was resolved recently. Custom window class is kept after restarts on Nightly 59.
No, still not working for me, it restarts with a different wm_class after updates.
Works for me with Nightly 59.0a1 (2017-12-29) on Ubuntu 17.10 using GNOME Shell (Xorg).
(In reply to Kestrel from comment #4)
> Works for me with Nightly 59.0a1 (2017-12-29) on Ubuntu 17.10 using GNOME
> Shell (Xorg).

Yeah, not working on Wayland.
Can confirm it does not work on Wayland.
> Anyway I think it would be helpful to not use "Firefox" for all Firefox build channels and also use different executable names for each one.

Yes, totally! Maybe better create a new bug for this, though as it could get lost in this one?
You need to log in before you can comment on or make changes to this bug.