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

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Martin Stránský [:stransky] (ni? me)]

The problem is that WM_CLASS is set by:

GetBrandName(brandName);
...
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 http://live.gnome.org/GnomeShell/ApplicationBased).

Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=692150

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

Comment 1

[Martin Stránský [:stransky] (ni? me)]

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

[Karl Tomlinson (:karlt)]

Might be a regression from bug 29856.

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

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

[Karl Tomlinson (:karlt)]

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

[Martin Stránský [:stransky] (ni? me)]

Anyway, the issue is fixed by patch in Bug 496653.