436784 - WM_CLASS is changed after mapping the window.

Status: RESOLVED WORKSFORME

(Firefox :: Shell Integration, defect)

Description

[Mikael Magnusson]

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

http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5
"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

[Mikel Ward]

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

[reikred]

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-2.0.0.16, it worked, and one can set the WM_CLASS
string to some user-defined value

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

ALL subwindows will get WM_CLASS set as above in firefox 2.0.0.16.

Comment 3

[rnmozbugs]

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.

Comment 4

[Karl Tomlinson (:karlt)]

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.