43108 - Ja chars in the window title are displayed as dots on a Ja Red Hat

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[ji]

Build: 2000061908 linux comm build.

On "Japanese" Red Hat 6.2, the Japanese characters in the window title are
displayed as
dots. Ja chars used to be displayed correctly on a Japanese Red Hat although 
they
are displayed as question marks in a English Red Hat + Japanese package
environment.

Steps of reproduce.
1. Launch browser
2. Open a EUC html file with Japanese title. (will attach a testing html file
later)

You'll see the japanese chars in the window title are displayed as dots.

Comment 1

[ji]

Attachment: Attached an EUC html file

Comment 2

[ji]

Specified Japanese system in the summary.

Comment 3

[Henrik Gemal]

On build 2000062020 on Win2k JA chars are displayes as ???? in the window title, 
even though the JA chars are displayed correctly in both the thread and message 
pane.

Comment 4

[Katsuhiko Momoi]

Gemal, what you're seeing is probably a seprate bug.
You're probably running non-Japanese Windows2000, is that
right? If so, there will be a generic Windows title display 
problem in supporting characters not native to that OS's
default language.
Whta this bug is about is that on Japanese OSs, the title
in Japanese should show correctly. 

Comment 5

[Frank Tang]

ji- What is your locale when you see the problem ? do a setenv (what is the LANG 
and LC_ALL ?)

Comment 6

[Frank Tang]

What will happen if you set LANG to ja and relaunch it?

Comment 7

[ji]

The locale I used for Japanese is ja_JP, which is the default Japanese locale
when you login from a Japanese login window. "ja" Japanese locale name is the
one we used in an En RH6.0 + Japanese packages environment and this "ja" locale
name is not usable anymore on Japanese Red Hat 6.2.
By the way the window title in an En RH6.0 + Japanese packages environment
also has Japanese displayed as dots.

Comment 8

[Frank Tang]

I though I fix this for Korean. [e-mail] qa that for me.
[e-mail] - can you verify this in the Korean locale ?

Comment 9

[Jungshik Shin]

As Frank wrote, it was fixed a few months ago at least for Korean. But,
I'm not sure what has happened since. I'll check it for Linux as soon as I'm
back from South America and my DSL link is up and running. As for other platforms,I tried
M16 under MacOS9 recently and it seems to work fine if I register it for
Korean using Language register(my memory is vague here so that
I have to try it again when I'm back)

Comment 10

[Frank Tang]

nsbeta3- per i18n bug meeting for now. Jungshik Shin , is this a regression on 
Linux . Forget about Mac or window in this bug. This is a linux only bug report. 

Comment 11

[Jungshik Shin]

I reported this bug back in January in the I18N newsgroup
(refer to <news://news.mozilla.org/84t9li$[e-mail]> and
follow-ups thereof by me and Frank) and Frank made a patch right away, which
fixed the problem. Howerver, the newest nightly build I've just tried (buils ID :
2000080421) has exactly the same bug. Somehow, the bug resurrected.
I'll check the source later. (now with my DSL link on, I can download the source)

Comment 12

[Katsuhiko Momoi]

ji observed this problem with the 6/19/2000 M17 Linux build.
I have an M16 build from 6/13/2000 and it is OK there.
So, it broke somewhere between M16 and M17.

 

Comment 13

[Frank Tang]

in the cvs log of mozilla/ widget/ src/ gtk/ nsWindow.cpp 
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/widget/src/gtk/nsWindow.cpp
1.290  dbaron%fas.harvard.edu  Aug 16 16:18   Fix string leaks from 
nsWindow::SetTitle. r=pavlov b=49148
1.285 <[e-mail]> 28 Jul 2000 16:59 fix for mem leak bug 43580 r=slamm
1.278 pavlov%netscape.com Jun 9 14:13  fix for some window managers not setting 
the titlebar anymore. nsbeta2+ bug 41786. r=bryner
1.274  pavlov%netscape.com Jun 6 17:11  fix for unix i18n title bug 36039 
r=alecf
1.271 pavlov%netscape.com May 3 14:46 try to speed up SetTitle a tad

Tajima-san, can you try this ? we probably should try the SetTitle in the 2.284 
version and see can we see this bug. 
Reassign this to tajima

Currently this bug is mark as nsbeta3-. But if we can get fix from sun, I think 
we can take the fix.

Comment 14

[Stuart Parmenter]

if the font used by your window manager for window titles isn't a japanese font,
then they probably won't display.

Comment 15

[Hidetoshi Tajima]

Attachment: comment out a block of codes to set a title in XStringStyle.

Comment 16

[Hidetoshi Tajima]

Japanese title is broken by "// TWM sucks and doesn't support compound text..
argh" and the next block of codes to set WM title in XStringStyle.
The problem is gone by commenting them out. Reassinging for review.

Comment 17

[Stuart Parmenter]

we have to do this check, otherwise TWM gets a blank window title.  if GetWMName
is returning failure and causing us to set it every time even when we shouldn't,
then that should be looked at.  I know this code works with sawfish.

Comment 18

[Hidetoshi Tajima]

Does the code works in sawfish even for JA title?
Does sawfish take JA title in STRING encoding??

Comment 19

[Hidetoshi Tajima]

Ah, the return value of XGetWMName should be evaluated reversely.
I'll attach a new code diff, please review it again.

Comment 20

[Hidetoshi Tajima]

Attachment: XStringStyle should be tried if XGetWMName is returning failure

Comment 21

[Hidetoshi Tajima]

Attached, hoping this is what you want.
I wonder we may use XStdICCTextStyle at the 1st call
instead of XCompoundTextStyle. We may skip the 2nd call
of XStringStyle.

Comment 22

[Stuart Parmenter]

could you please post a patch against the current version of nsWindow from CVS?

Comment 23

[Stuart Parmenter]

Attachment: patch

Comment 24

[Stuart Parmenter]

Attachment: er, ignore previous patch.. look at this one

Comment 25

[Stuart Parmenter]

is this last patch right?  if so, r=pavlov

Comment 26

[Hidetoshi Tajima]

 >could you please post a patch against the current version of nsWindow from
CVS?
A quetion. Your patch(15:32) is from the revision 1.288,
while mine(14:40) is from the 1.292.
 >is this last patch right?  if so, r=pavlov
Which patch shall be checked-in?

Comment 27

[Stuart Parmenter]

argh, i'm not up to date.. sorry. check in yours.

Comment 28

[Hidetoshi Tajima]

Thanks. I sent Code diffs(14:40) to [e-mail] for check-in approval.

Comment 29

[Hidetoshi Tajima]

check in, a=wateron.

Comment 30

[Decklin Foster]

This checkin just broke bug XXXXX again (aka "TWM sucks"). I'm reopening it. We
should not be using COMPOUND_TEXT unless a locale is set that requires it.

Argh, bugzilla is horked at the moment so I'll find the other bug later.

Comment 31

[Decklin Foster]

Ok, the bug I was thinking of is 41786. What this fix breaks is the use of
XFetchName() to get the window title. I don't think that we should require
window managers to do something special here: XFetchName() is the standard way
to read the WM_NAME property.

Comment 32

[Hidetoshi Tajima]

Does it work using XStdICCTextStyle instead of COMPOUND_TEXT at the 1st
XmbTextListToTextProperty call? The encoding would be STRING
if given text is convertible to STRING, else COMPOUND_TEXT. Decklin, will 
you give a try?
BTW, XFetchName only works when the title string is STRING convertible,
so I don't think using this can the solution for i18n requirement.

Comment 33

[Decklin Foster]

Doesn't work, unfortunately... I'll see if I can hack on it.

Comment 34

[Decklin Foster]

Argh, ignore that past comment, I changed the wrong call (line 2227). Changing
the style on the first call (line 2204) does fix it. This looks like the right
thing to do. Can you check this in?

Comment 35

[Hidetoshi Tajima]

Attachment: use XStdICCTextStyle instead of COMPOUND_TEXT

Comment 36

[Hidetoshi Tajima]

checked in the fix.

Comment 37

[ji]

Verified with linux 2000082906 build.