WM_CLASS is changed after mapping the window.




Shell Integration
10 years ago
6 years ago


(Reporter: Mikael Magnusson, Unassigned)


3.0 Branch

Firefox Tracking Flags

(Not tracked)




10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071103 Firefox/
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0

"This property must be present when the window leaves the Withdrawn state and may be changed only while the window is in the Withdrawn state."

When mapping the window, the second field of WM_CLASS is set to "Firefox-bin", but shortly thereafter, it is changed to "Firefox". This is confusing for a lot of people trying to configure their window manager to match firefox windows as they use xprop to check WM_CLASS when the window is mapped.

Reproducible: Always

Steps to Reproduce:
1. Set up a window manager to match class=Firefox
2. Start firefox
Actual Results:  
The window is not matched

Expected Results:  
The window is matched

Comment 1

10 years ago
Yep.  I'm using Openbox and I have to set the class to "Firefox*" instead of "Firefox" to match Firefox windows.

Is there any need for it to change from Firefox-bin to Firefox?

Comment 2

9 years ago
Along the same lines as this bug: Why does it no longer work to use

firefox --class=Firefox1
firefox --class=Firefox2

and so on to set WM_CLASS in firefox-3.01. This feature is essential if one wants to have multiple firefox instances that are also distinguishable by the window  manager. As of firefox-, it worked, and one can set the WM_CLASS
string to some user-defined value

#version started with --class=Firefox6 
% xprop | grep WM_CLASS
WM_CLASS(STRING) = "gecko", "Firefox6"

ALL subwindows will get WM_CLASS set as above in firefox

Comment 3

9 years ago
I'd also like to add that the -a command line argument is completely broken.  On the first invocation, it starts firefox up normally, but doesn't seem to do anything to any of the window properties.  So a subsequent invocation with the same application id tries to find the running window, doesn't, and so tries to start a new instance -- leading to a locked profile error.  This is really obnoxious for those of us that run multiple profiles and want to set up automated scripts for launching windows in one profile or another.  Without a working -a option, this is impossible.


7 years ago
Version: unspecified → 3.0 Branch
This (comment 0) works for me both in the sense that there is no longer a -bin suffix, so the second field doesn't change, and that the first field changes from "Toplevel" to "Navigator" before the window is mapped.
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.