Closed Bug 849571 Opened 12 years ago Closed 3 years ago

WM_CLASS changes after a restart (gnome-shell)

Categories

(Firefox :: Shell Integration, defect)

Product:
Firefox
Component:
Shell Integration
Version:
21 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: micmon, Unassigned)

References

(Blocks 1 open bug)

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

Yes, totally! Maybe better create a new bug for this, though as it could get lost in this one?

I was trying to look up whether that is already solved or so or create a new bug, but apparently it is solved. Bug 1151753.

This works with X11 but not with Wayland, setting blocking dependency accordingly.

Blocks: wayland
See Also: → 1530052

Should work now on Wayland as well.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.