The default bug view has changed. See this FAQ.

WM_CLASS class string is localized, breaks gnome-shell (gnome3)

RESOLVED FIXED in mozilla14



Widget: Gtk
5 years ago
5 years ago


(Reporter: Martin Stránský, Assigned: Martin Stránský)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)





5 years ago
The problem is that WM_CLASS is set by:

class_hint->res_class = ToNewCString(brandName);

which breaks gnome-shell for some languages (chinese/pakistan/korean and so) because WM_CLASS is supposed to match .desktop file name (see

Downstream bug:

There are some related bugs: 
Bug 196238
Bug 436784 
Bug 496653

Comment 1

5 years ago
We should find a solution which works with official mozilla binaries (which are affected too), so the ENV variable or command line argument is not a good solution.
Might be a regression from bug 29856.
'A string that names the general class of applications to which the client that owns this window belongs. Resources that are specified by class apply to all applications that have the same class name. Class names are specified by the application writer. Examples of commonly used class names include: "Emacs", "XTerm", "XClock", "XLoad", and so on.'

I would assume that resource class names shouldn't differ according to locale.

When converting selections, at least,
'STRING as a type or a target specifies the ISO Latin-1 character set plus the control characters TAB (octal 11) and NEWLINE (octal 12). The spacing interpretation of TAB is context dependent. Other ASCII control characters are explicitly not included in STRING at the present time.'

But, when window managers group applications by program name, I assume they are using WM_CLASS as there is no other suitable property.  I guess they can and should look up this class via the desktop file to get the localized name, and maybe they already do that because GTK apps don't localize the WM_CLASS.
Summary: WM_CLASS name is localized, breaks gnome-shell (gnome3) → WM_CLASS class string is localized, breaks gnome-shell (gnome3)
kwin doesn't seem to be doing a lookup via the desktop file.  It shows Firefox, not Mozilla Firefox, which is in the desktop file.

Nightly and Aurora are going to end up both having class Firefox, but I guess if that were a problem the executable would have a different name.
Blocks: 335068
Keywords: regression

Comment 4

5 years ago
Anyway, the issue is fixed by patch in Bug 496653.
Last Resolved: 5 years ago
Resolution: --- → FIXED
Depends on: 496653
Target Milestone: --- → mozilla14
You need to log in before you can comment on or make changes to this bug.