Last Comment Bug 737791 - WM_CLASS class string is localized, breaks gnome-shell (gnome3)
: WM_CLASS class string is localized, breaks gnome-shell (gnome3)
: regression
Product: Core
Classification: Components
Component: Widget: Gtk (show other bugs)
: Trunk
: x86_64 Linux
-- normal (vote)
: mozilla14
Assigned To: Martin Stránský
Depends on: 496653
Blocks: 335068
  Show dependency treegraph
Reported: 2012-03-21 03:16 PDT by Martin Stránský
Modified: 2012-04-17 14:40 PDT (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Martin Stránský 2012-03-21 03:16:05 PDT
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 User image Martin Stránský 2012-03-21 08:15:21 PDT
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.
Comment 2 User image Karl Tomlinson (:karlt) 2012-03-21 19:13:37 PDT
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.
Comment 3 User image Karl Tomlinson (:karlt) 2012-03-22 16:37:06 PDT
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.
Comment 4 User image Martin Stránský 2012-04-17 04:41:41 PDT
Anyway, the issue is fixed by patch in Bug 496653.

Note You need to log in before you can comment on or make changes to this bug.