118700 - window title (WM_NAME) is Latin1 unconditionally

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[robbe]

widget/src/gtk/nsWindow.cpp tries to be smart about the charset the WM_NAME
property should be in. This is wrong. ICCCM 4.1.2.1.:

  The encoding used for this string (and all other uninterpreted
  string properties) is implied by the type of the property.
  The type atoms to be used for this purpose are described in
  section 2.7.1.

ICCCM 2.7.1.:

  STRING as a type or a target specifies the ISO Latin-1
  character set plus the control characters TAB (hex 09) and
  NEWLINE (hex 0A).  The spacing interpretation of TAB is
  context dependent.  Other ASCII control characters are
  explicitly not included in STRING at the present time.

The effect is that perfectly fine Latin1 characters (like ö) end up as "?"
if Mozilla makes out that the platform charset should be US-ASCII. I'll attach a
patch that unconditionally uses ISO-8859-1 as charset.

Comment 1

[robbe]

Attachment: patch 1

Comment 2

[jag (Peter Annema)]

Attachment: Updated to trunk

Comment 3

[jag (Peter Annema)]

Comment on attachment 63966 [details] [diff] [review]
Updated to trunk

r=syd, sr=jag

Comment 4

[Christopher Blizzard (:blizzard)]

I'm 99% sure that this is incorrect.  I think that WM_NAME should be in the
current charset, not always in ISO-8859-1.

hp + owen might be able to back me up here.

Comment 5

[otaylor]

The bug report is correct that if WM_NAME has type STRING, then it would
be latin-1 plus t and \n.

However, for anything but a latin-1 locale, gtk_window_set_title() will
use COMPOUND_TEXT to correctly represent the title in that locale.
(This is actually all handled in Xlib.)

So, gtk_window_set_title() expects its input to be in the encoding
of the locale.

Comment 6

[Christopher Blizzard (:blizzard)]

So, given that this patch should be completely unnecessary, right?

Comment 7

[Havoc Pennington]

My patch to just use gtk_window_set_title() and avoid any Xlib games went in, right?

GTK wants locale encoding. Always. All GTK functions take locale encoding. 
GTK will take care of setting the X properties in the right format. 
Mozilla needs to take care of giving GTK _locale encoding_. ;-)
No other encoding. No Latin-1. No Unicode. ;-)

gtk_window_set_title() does the right thing. Just give it locale encoding, and
stop fooling with the window title code - if gtk_window_set_title() doesn't
work, your window manager is broken.

Of course in GTK 2, it all changes - GTK always wants UTF-8, never anything else.

Comment 8

[otaylor]

The patch is 100% bogus. It's hard to say what is _actually_ wrong,
since there is no report of a bug in this bug report; perhaps 
detection of the locale charset was failing on some platform.

Comment 9

[jag (Peter Annema)]

Given the above comments, I'd say the current code seems to be doing the right
thing.

The problem seems to be that a character like 

Comment 10

[robbe]

otaylor: See the last paragraph of my initial report.

The problem is that in the C locale Mozilla thinks that US-ASCII is the way to
go and removes Latin1 characters from the string. GTK still uses STRING (and
thus Latin1) in this case because in X Latin1 is the lowest common denominator,
not ASCII.

Perhaps when ASCII is determined as the locale encoding, this special case
should be upgraded to latin1?

Comment 11

[otaylor]

IMO, no. Many other features of your desktop won't work properly if
you don't have an appropriately set locale. There is certainly no
guarantee that Xlib (and hence GTK+) will work properly if you pass
it data not in the encoding of the locale.

Yes, special casing could be added to say "If the locale's encoding
is ASCII, then Mozilla bypasses GTK+ and Xlib and sets WM_NAME 
directly since it knows how to convert Unicode into Latin1."

But IMO, this is just adding complexity and delaying the inevitable. 
If your LC_CTYPE/LANG is C, your telling the operating system to "only handle
ASCII". For correct operation, the locale must be set to something 
that the operating system can handle, which for Western European characters,
means a locale using ISO-8859-1, ISO-8859-15, or UTF-8. 

(Many window managers now read, or will soon read the _NET_WM_NAME UTF-8 
property anyways.)

Comment 12

[Christopher Blizzard (:blizzard)]

Marking this as invalid.