Last Comment Bug 9449 - window titlebar does not render non-English [unicode] text properly
: window titlebar does not render non-English [unicode] text properly
Status: VERIFIED FIXED
[eta 8/16/2002]
: helpwanted, intl
Product: Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: x86 Windows XP
: P2 normal with 11 votes (vote)
: mozilla1.2beta
Assigned To: Roy Yokoyama
: Yuying Long
: Makoto Kato [:m_kato]
Mentors:
http://www.netscape.com/ja
: 2426 33597 34495 48169 56970 61126 61676 75344 82252 82950 105921 108418 114792 128174 131558 131868 135718 135908 136683 137143 138916 149908 152788 152839 154881 154903 157687 161248 168950 174539 175673 182949 185816 188764 (view as bug list)
Depends on: 97671 118013 166735 180372
Blocks: 88384 104320 104500 unicode
  Show dependency treegraph
 
Reported: 1999-07-08 14:06 PDT by tao
Modified: 2014-01-28 05:37 PST (History)
60 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Adds a _NET_WM_NAME(UTF8_STRING) property to windows on X11 (1.04 KB, patch)
2001-05-29 14:31 PDT, Ilya Konstantinov
no flags Details | Diff | Splinter Review
A fix to my previous faulty patch. (2.10 KB, patch)
2001-07-03 16:16 PDT, Ilya Konstantinov
no flags Details | Diff | Splinter Review
The same patch, with jag's suggestion. Tested against fixed kwin (as would come with KDE 2.2). (2.05 KB, patch)
2001-07-11 07:14 PDT, Ilya Konstantinov
no flags Details | Diff | Splinter Review
a patch for Windows NT4/2k/XP (4.20 KB, patch)
2001-11-25 14:38 PST, Jungshik Shin
no flags Details | Diff | Splinter Review
a new patch(bas. the same) for WIn2k/NT4/XP (5.16 KB, patch)
2001-11-27 21:31 PST, Jungshik Shin
no flags Details | Diff | Splinter Review
a new patch for Win2k/NT/XP that does work (15.04 KB, patch)
2002-03-22 11:05 PST, Jungshik Shin
no flags Details | Diff | Splinter Review
stack backtrace : access violation error with my patch (20.81 KB, text/plain)
2002-04-07 15:22 PDT, Jungshik Shin
no flags Details
revising jshin's patch (22.82 KB, patch)
2002-06-06 09:27 PDT, Roy Yokoyama
no flags Details | Diff | Splinter Review
revising jshin's patch (22.82 KB, patch)
2002-06-06 09:28 PDT, Roy Yokoyama
no flags Details | Diff | Splinter Review
Compiled :) (23.38 KB, patch)
2002-06-06 10:15 PDT, Roy Yokoyama
no flags Details | Diff | Splinter Review
define MOZ_UNICODE environment variable (17.96 KB, patch)
2002-06-07 10:04 PDT, Roy Yokoyama
no flags Details | Diff | Splinter Review
Oops, forgot to include nsWindowAPI.h (31.90 KB, patch)
2002-06-07 10:21 PDT, Roy Yokoyama
no flags Details | Diff | Splinter Review
Removing un-necessary part (23.85 KB, patch)
2002-06-07 10:23 PDT, Roy Yokoyama
no flags Details | Diff | Splinter Review
Ahhhh wrong DEFINES (23.87 KB, patch)
2002-06-07 10:49 PDT, Roy Yokoyama
no flags Details | Diff | Splinter Review
use of W-APIs only (21.29 KB, patch)
2002-06-21 11:44 PDT, Roy Yokoyama
no flags Details | Diff | Splinter Review
taking shanjian's recommendation (22.48 KB, patch)
2002-06-26 12:25 PDT, Roy Yokoyama
shanjian: review+
Details | Diff | Splinter Review
adding kin's recommendations (23.11 KB, patch)
2002-06-28 16:27 PDT, Roy Yokoyama
kinmoz: superreview+
Details | Diff | Splinter Review
Need -DMOZ_UNICODE for \\webshell\test\makefile.* (1.97 KB, patch)
2002-07-25 10:36 PDT, Roy Yokoyama
no flags Details | Diff | Splinter Review
Need to support WindowPopupClass() and WindowClass() (1.22 KB, patch)
2002-07-26 16:42 PDT, Roy Yokoyama
no flags Details | Diff | Splinter Review
Revised (2.05 KB, patch)
2002-07-29 10:10 PDT, Roy Yokoyama
shanjian: review+
kinmoz: superreview+
asa: approval+
Details | Diff | Splinter Review
Problems with charset Western ISO-8859-1 (152.22 KB, application/octet-stream)
2002-08-20 09:50 PDT, Sobrinho
no flags Details
Test case (802 bytes, text/plain)
2002-10-02 10:26 PDT, 石庭豐 (Seak, Teng-Fong)
no flags Details

Description tao 1999-07-08 14:06:17 PDT
TO reproduce this:

1. Copy and paste a Ja text in unicode to your XUL file as the
   title text of the top level window. And run the client to
   open the affected window.
2. On Linux, under Ja env. (ja_JP.ujis), the title text renders
   as garbage. Same thing would happen on Mac.

This is a problem similar to http://bugzilla.mozilla.org/show_bug.cgi?id=7822
Comment 1 tao 1999-07-08 14:07:59 PDT
Log a bug to keep track of this problem.
Comment 2 saari (gone) 1999-08-10 17:51:59 PDT
Tague, on the Mac, can I copy the code from nsMenu into nsMenuBar for menu title
internationalization, or is there something else I need to do?

As for the other platforms, I believe XPMenus fixes this issue.
Comment 3 bobj 1999-08-10 18:13:59 PDT
XPmenus should have nothing to do with title bars.
Comment 4 saari (gone) 1999-08-10 20:31:59 PDT
You're right, I mistakenly read this bug as top level menu titles.

So why do I have this bug then?
Comment 5 tao 1999-08-11 09:38:59 PDT
Thought that this is an XPWidgets related problem :-).

Who might be the lucky owner, any idea?
Comment 6 saari (gone) 1999-08-25 17:48:59 PDT
Eh, I'm going to assign this to danm with this note: I believe our window titles
are as internationalized as they're going to get. Tague, do you agree? If so,
lets close this bug...
Comment 7 tague 1999-08-25 19:46:59 PDT
sarri :- no, this is still a valid bug.

right now there is extraneous ToNewCString calls in setting the top level window
title.  non-english characters are getting lost even on non-english systems.
for instance, on my japanese NT box, Japanese page titles are displayed as
"....".  that doesn't work.

the baseline functionality is that the window title has to draw correctly if the
langauge can be rendered in the system script -- meaning a japanese system has
to correctly get japanese titles, and english system doesn't.

i'm not sure how far we want to push owner-draw of menu titles and a full
multi-lingual menu title.  due to technical limitations, i'm willing to accept
the baseline functionality for Mac (Japanese only on a Japanese system), but I
think we should push for correct Unicode display on windows and unix if
possible.
Comment 8 tague 1999-09-08 12:15:59 PDT
Tao: could you please attach a Japanese localized XUL file to this bug, so that
people have something to test with.  You can also view the problem by visiting
a Japanese website with a Japanese tittle page.  You can use
http://www.netscape.com/ja to demonstrate the problem.  You should get
Netcenter へようこそ" (welcome to Netcenter) in your titlebar, but instead with
seamonkey you get .... because of the ToNewCString problem outlined above.


Look at the code I gave to Saari for menus as a boilerplate.
Comment 9 chris hofmann 1999-09-09 10:23:59 PDT
how critical is this for beta1?
Tao's test case isn't posted yet.
Can we figure out if there is a way to get help and right ownership on this?
Comment 10 tao 1999-09-09 10:51:59 PDT
This bug can be easily reproduced by loading Netscape's Japanese home page,
http://www.netscape.com/ja. But, I'll see if there is a dialog I can hack
with and also retest this bug.

If I attach a Seamonkey *.dtd or *.xul files, they might become outdated when
the original *.dtd file got changed and prevent the XUL page from being
loaded correctly.

Please let me know if this bug can't be reproduced by loading the Japanese
page.

Inserting the Ja home page to the URL field.


Thanks
Comment 11 tague 1999-09-09 12:01:59 PDT
this is a beta-1 blocker.
Comment 12 Frank Tang 1999-09-11 01:11:59 PDT
jliu (used work for Netscape) have some old code in the gromit tree which use NC
stuff (Not Client area) to draw unicode for Window. That might help you solve
this one Window.
Comment 13 Frank Tang 1999-09-17 00:05:59 PDT
For window platform, jliu two years ago add the following code to make it
display Unicode text.

http://lxr.mozilla.org/mozilla/source/cmd/winfe/genframe.cpp#301
219
220
221 #ifdef XP_WIN32
222 // jliu added the following to support CJK caption print
223 int16 CGenericFrame::GetTitleWinCSID()
224 {
225     CWinCX *pContext = GetMainWinContext();
226     MWContext* pMWContext = NULL;
227     if( pContext == NULL || ( pMWContext = pContext->GetContext() ) == NULL
){
228         return -1;
229     }
230     INTL_CharSetInfo csi = LO_GetDocumentCharacterSetInfo(pMWContext);
231
232     return INTL_GetCSIWinCSID(csi);
233 }
234
235 ////////////////////////////////////////////////////////////////////
236 // this function is called outside to get the wincsid
237 // and then setup the Caption Font.
238 //
239 void CGenericFrame::SetupCapFont( int16 csid, BOOL force )
240 {
241     if( !force && ( m_csid == csid ) && ( hCapFont.m_hObject != NULL ) )
242         return;
243
244     // set the wincsid
245     if( csid <= 0 )
246         m_csid = CIntlWin::GetSystemLocaleCsid();
247     else
248         m_csid = csid;
249
250     // set the caption print font
251     if( hCapFont.m_hObject != NULL )
252         hCapFont.DeleteObject();
253
254     // get the system caption print font first
255     NONCLIENTMETRICS nc;
256     nc.cbSize = sizeof(NONCLIENTMETRICS);
257     BOOL b = SystemParametersInfo( SPI_GETNONCLIENTMETRICS,
sizeof(NONCLIENTMETRICS), &nc, 0 );
258     XP_ASSERT( b );
259
260     LOGFONT lf = nc.lfCaptionFont;  // get the logic font used to paint the
caption
261     csid = CIntlWin::GetSystemLocaleCsid();
262     if( force || ( m_csid !=  csid ) ){             // in case user changes
system font
263         lf.lfCharSet = IntlGetLfCharset( m_csid );
264         _tcscpy( lf.lfFaceName, IntlGetUIPropFaceName( m_csid ) );
265         hCapFont.CreateFontIndirect( &lf );
266     }
267
268     // create the default font if the above step failure
269     if( hCapFont.m_hObject == NULL ){
270         hCapFont.CreateFontIndirect( &nc.lfCaptionFont );
271         m_csid = csid;
272     }
273 }
274
275 //////////////////
276 // User changed system settings, such  as font. Or changed
277 // encoding method, coming from compfrm.cpp
278 // Invalidate everything to generate anew.
279 //
280 LRESULT CGenericFrame::OnSettingChange( WPARAM, LPARAM )
281 {
282     SetupCapFont( GetTitleWinCSID(), TRUE );
283     SendMessage(WM_NCPAINT);
284     return 0;
285 }
286
287
288 //////////////////
289 // Someone called SetWindowText: paint new text.
290 //
291 LRESULT CGenericFrame::OnSetText(WPARAM wParam, LPARAM lParam)
292 {
293     SetupCapFont( GetTitleWinCSID() );
294
295     // Turn WS_VISIBLE style off before calling Windows to
296     // set the text, then turn it back on again after.
297     //
298     DWORD dwStyle = GetStyle();
299     if( dwStyle & WS_VISIBLE )
300         SetWindowLong( m_hWnd, GWL_STYLE, dwStyle & ~WS_VISIBLE );
301     LRESULT lRet = DefWindowProc(WM_SETTEXT, wParam, lParam);
302     if( dwStyle & WS_VISIBLE )
303         SetWindowLong( m_hWnd, GWL_STYLE, dwStyle );
304
305     SendMessage(WM_NCPAINT);        // paint non-client area (frame too)
306
307     return lRet;
308 }
309
310 //////////////////
311 // Non-client area (de)activated: paint it
312 //
313 BOOL CGenericFrame::OnNcActivate(BOOL bActive)
314 {
315     if( m_nFlags & WF_STAYACTIVE )
316         bActive = TRUE;
317     if( !IsWindowEnabled() )
318         bActive = FALSE;
319     if( bActive == m_bActive )
320         return TRUE;
321
322     MSG& msg = AfxGetThreadState()->m_lastSentMsg;
323     if( msg.wParam > 1 )
324         msg.wParam = TRUE;
325     m_bActive = bActive = msg.wParam;
326
327     // Turn WS_VISIBLE off before calling DefWindowProc,
328     // so DefWindowProc won't paint and thereby cause flicker.
329     //
330     DWORD dwStyle = GetStyle();
331     if( dwStyle & WS_VISIBLE )
332         ::SetWindowLong(m_hWnd, GWL_STYLE, (dwStyle & ~WS_VISIBLE));
333     DefWindowProc(WM_NCACTIVATE, bActive, 0L);      // don't call
CFrameWnd::OnNcActivate()
334     if( dwStyle & WS_VISIBLE )
335         ::SetWindowLong(m_hWnd, GWL_STYLE, dwStyle);
336
337     SendMessage( WM_NCPAINT );      // paint non-client area and frame
338
339     return TRUE;
340 }
341
342
343 void CGenericFrame::OnNcPaint()
344 {
345     DWORD dwStyle = GetStyle();
346     if( !( dwStyle & WS_CAPTION )  ){
347         CFrameWnd::OnNcPaint();                 // do the default one first
348         return;
349     }
350
351     CSize szFrame = (dwStyle & WS_THICKFRAME) ?
352         CSize(GetSystemMetrics(SM_CXSIZEFRAME),
353                GetSystemMetrics(SM_CYSIZEFRAME)) :
354         CSize(GetSystemMetrics(SM_CXFIXEDFRAME),
355                 GetSystemMetrics(SM_CYFIXEDFRAME));
356
357     int dxIcon = GetSystemMetrics(SM_CXSIZE); // width of caption
icon/button
358
359     // Compute rectangle
360     CRect rc;               // window rect in screen coords
361     GetWindowRect( &rc );
362     rc.left  += szFrame.cx;                         // frame
363     rc.right -= szFrame.cx;                         // frame
364     rc.top   += szFrame.cy;                         // top = end of frame
365     rc.bottom = rc.top + GetSystemMetrics(SM_CYCAPTION)  // height of
caption
366         - GetSystemMetrics(SM_CYBORDER);                                  //
minus gray shadow border
367
368
369     MSG& msg = AfxGetThreadState()->m_lastSentMsg;
370
371     // Don't paint if the caption doesn't lie within the region.
372     //
373     if (msg.wParam > 1 && !::RectInRegion((HRGN)msg.wParam, &rc)) {
374         CFrameWnd::OnNcPaint();                 // do the default one first
375         return;                                                 // quit
376     }
377
378
379     // setup the update region, include the title text region
380
381     CRect rectCaption;
382     GetWindowRect( &rectCaption );
383
384     CWindowDC dc(this);
385     CFont* hFontOld = dc.SelectObject( &hCapFont );
386
387     HRGN hRgnCaption = ::CreateRectRgnIndirect(&rc);
388     HRGN hRgnNew     = ::CreateRectRgnIndirect(&rc);
389     if( msg.wParam > 1 ){
390         // wParam is a valid region: subtract caption from it
391         ::CombineRgn( hRgnNew, (HRGN)msg.wParam, hRgnCaption, RGN_OR );
392     } else {
393         // wParam is not a valid region: create one that's the whole window
394         DeleteObject( hRgnNew );
395         hRgnNew = ::CreateRectRgnIndirect(&rectCaption);
396     }
397
398     // call the default NcPaint
399
400     WPARAM savewp = msg.wParam;             // save original wParam
401     msg.wParam = (WPARAM)hRgnNew;   // set new region for DefWindowProc
402     CFrameWnd::OnNcPaint();                 // paint the caption bar except
title text
403     DeleteObject( hRgnCaption );    // clean up
404     DeleteObject( hRgnNew );                // clean up
405     msg.wParam = savewp;                    // restore original wParam
406
407
408     // Compute rectangle
409     // Within the basic button rectangle, Windows 95 uses a 1 or 2 pixel
border
410     // Icon has 2 pixel border on left, 1 pixel on top/bottom, 0 right
411     // Close box has a 2 pixel border on all sides but left, which is zero
412     // Minimize button has 2 pixel border on all sides but right.
413
414     rectCaption -= rectCaption.TopLeft(); // convert caption rectangle
origin to (0,0)
415     rectCaption.left  += (szFrame.cx + 2 + dxIcon);
416     rectCaption.right -= (szFrame.cx + 2 + dxIcon);
417     rectCaption.top   += szFrame.cy;                                // top =
end of frame
418     rectCaption.bottom = rectCaption.top + GetSystemMetrics(SM_CYCAPTION)
// height of caption
419         - GetSystemMetrics(SM_CYBORDER);                        // minus
gray shadow border
420
421
422     // i don't know why MS supports this feature ...
423     if( ( dwStyle & WS_MAXIMIZEBOX ) || ( dwStyle & WS_MINIMIZEBOX ) ){
424         rectCaption.right -= ( dxIcon + 2 + dxIcon );
425         if( capStyle != DT_LEFT )       // for NT 3.51
426             rectCaption.right += dxIcon + 4;
427     }
428
429     // create a brush for caption background
430     CBrush brCaption;
431     brCaption.CreateSolidBrush(
432         ::GetSysColor( m_bActive ? COLOR_ACTIVECAPTION :
COLOR_INACTIVECAPTION ) );
433
434     CString strTitle;
435     GetWindowText( strTitle );
436
437     //dc.FillRect(&rectCaption, &brCaption);
438     dc.SetTextColor(::GetSysColor(m_bActive ? COLOR_CAPTIONTEXT :
COLOR_INACTIVECAPTIONTEXT));
439     dc.SetBkMode(TRANSPARENT);
440
441     int titleLen = _tcslen( strTitle );
442     UINT cs = capStyle;
443     if( cs != DT_LEFT ){    // it is NT 3.51
444         CSize size = dc.GetTextExtent( strTitle, titleLen );
445         if( size.cx >= rectCaption.Width() )
446             cs = DT_LEFT;
447     }
448     CIntlWin::DrawText( m_csid, (HDC)dc, strTitle.GetBuffer( titleLen ),
titleLen,
449         &rectCaption, cs|DT_VCENTER|DT_SINGLELINE|DT_END_ELLIPSIS );
450
451     dc.SelectObject(hFontOld);
452 }
453
454 #endif  // #ifdef XP_WIN32
455

The main point is he use OnNcPaint to draw the window title by him self. The
code should be simpler because in that time he need also keep track of the csid
of the origional text but now we can always count nsString as unicode.
Comment 14 Dan M 1999-09-17 11:59:59 PDT
A pox on whoever moved this back to M11 on me. While I appreciate Frank's digging up
the windows Nav code to handle this problem, it's not trivial, especially in an XP sense, and
garbage in the window titlebar on some systems doesn't stack up in comparison to my other
M11 bugs. The moniker "beta-1 blocker" begins to lose its value when it's overused so.
  I'm leaving it M11 in the vain hope that the combination of that and Help Wanted in the
status whiteboard will attract outside interest, but in the interest of honesty, plan on its being
shoved back to M15 along with a lot of other bugs, as the deadline approaches.
  I do remain confused why i18n doesn't want this bug.
Comment 15 tague 1999-09-17 12:11:59 PDT
Reopening this.....this is not a laterable bug - this is a beta blocker.
Japanese window title text does not correctly display on a Japanese system.  The
window titleing code is incorrect and the owners need to fix this.

There is a big misconception that the i18n group is reponsible for anything that
doesn't work in languages other than English.  That is not the case -- the
"core" (non-i18n teams) have the responsibility to fix i18n bugs in their code.
Comment 16 tague 1999-09-17 12:12:59 PDT
clearing resolution.
Comment 17 tague 1999-09-17 12:22:59 PDT
Pasting from the Seamonkey Beta critera :-

international users will be able to use seamonkey: browse sites, compose, read
and write mail in Japanese and Latin 1 languages.

this bug falls into that criteria
Comment 18 Frank Tang 1999-09-17 13:17:59 PDT
danm: I know you are busy for a lot of thing. But please understand no one "A
pox on whoever moved this back to M11 on me" before 09/17/99 11:59. Please read
the "View Bug Activity" log and you will find out it is yourself move this bug
from M10 to M11 to yourself at 1999-09-07 18:01:10.

Mark this as RESOLVED LATER without fixing it is not acceptable. Thanks tague
for reopening it.

Please do not feel we are pushing your (we don't). We all know this is not
trivial but please do not ignore/underestimate the need.

Except tague REOPEN this bug after your mark it "RESOLVED LATER", no one from
i18ngrp ever change the target_milestone/bug_status/resolution field of this bug
(Again, read "View Bug Activity" for details)
Comment 19 Dan M 1999-09-17 13:39:59 PDT
Well, a pox on me, then. I had intended to move this bug past M11.  Thought I had.
Nevertheless, in marketing's criterion quoted above by tague, I fail to see how garbage
in the window title affects useability.  I'm calling in an arbitrator.
Comment 20 Peter Trudelle 1999-09-17 14:11:59 PDT
setting p3 for m14. If by some miracle we finish with the critical beta-blocker
problems that affect _every_ user, then we'll see about possibly looking at
this.
Comment 21 tague 1999-09-17 14:46:59 PDT
let's get real, what you are saying is we aren't going to fix things unless they
affect english users.

that is not an acceptable prioritization of bugs. this is essential for shipping
the i18n beta, we have a product goals that we have to make -- and just because
"all" users aren't affected doesn't mean they aren't valid goals.
Comment 22 Dan M 1999-09-17 15:21:59 PDT
Sigh.  C'mon guys, this _is_ us trying to be real.  There's no time for this in M11.  Garbage in
the titlebar doesn't stack up against my other bugs.  Something has to slip.  This won't be the
only one.  I suppose you gave me this bug because you're out of time, but so am I.
Comment 23 Peter Trudelle 1999-09-17 15:54:59 PDT
This isn't a UCan vs I18N issue for us, it is a matter of fixing bugs that
affect everyone or only a subset of users.  We have to fix the critical bugs
that affect everyone first.  I would declare and ship beta with this bug if we
didn't have time to fix it, so I'm not putting it on my must-fix-for-beta list.
 I'm willing to listen to any rational argument why I'm full of it, and you're
also welcome to petition higher authorities.
Comment 24 Frank Tang 1999-09-17 16:58:59 PDT
Everybody cool down.
1. Please read the previous "Comments From tague@netscape.com  08/25/99 19:46."

There are two level of fix:
Level 1- Display French/German text correctly on US window/mac/Linux. and
display Japanese text correctly on Japanse window/mac/linux. It will display
Japanese as garbage in US window/mac/Linux and French/German text as garbage in
Japanese window.

To do this , it is not too difficult. It need to replace the
nsString::ToNewCString code with the correct convert to
CP_ACP/SystemScript/locale_charset call.

2. Level 2- Need to use MW_NCPAINT on Window (and other tech on Mac/Linux) .
This need jliu's NCPAINT work and is not trival.

I think it is reasonable to shoot for level 1 in beta1 and level 2 for post
beta.

If you feel display title as garbage text is *not important* in beta,then why
don't we remove the title display text at all (display blank) so it won't make
our Japanese user feel bad? Can you accept that ?
Comment 25 Frank Tang 1999-09-17 17:44:59 PDT
trudelle: Please understand that unfortunately your "a subset of users" is our
"everyone".
Comment 26 Frank Tang 1999-09-22 00:43:59 PDT
OK... James Toder kindly submit a simple fix for the Level 1 on window. Can we
now move this to M12 and let danm merge that patch ?
Dan, the mail is also send to you. But in case you lost it , you can find it in
the mozilla-i18n newsgroup.
Move this bug back to M12 so danm can check in the patch.
Comment 27 Frank Tang 1999-09-22 01:02:59 PDT
Please understand, "it is a matter of fixing bugs that affect everyone or only a
subset of
users." is a bad criteria for priority. You won't allow the product go beta if
the title always
display Y as X and X as Y , right ? (It will then only affect the subset of
users which view
pages that have title including character X and Y. )  Actually, this IS a bug
which affect
everyone. The page won't display any Non ASCII in the title correctly, including
Tradmark,
copyright, registration mark, etc. It IS a bug which affect everyone. Unless
your subset of
user only referred to those user who do not view the page title which include
those
characters.

For example, the english page
http://microsoft.com/presspass/features/1999/09-20sparks.htm
won't display correctly on Mac and Linux (Probably not even window, without
James' patch)
Comment 28 Dan M 1999-10-22 15:18:59 PDT
James Toder's partial unicode-to-multibyte patch checked in.
Comment 29 Frank Tang 2000-03-29 11:12:45 PST
*** Bug 2426 has been marked as a duplicate of this bug. ***
Comment 30 Frank Tang 2000-03-29 11:14:01 PST
*** Bug 33597 has been marked as a duplicate of this bug. ***
Comment 31 Jungshik Shin 2000-03-29 12:24:36 PST
  This bug has been RESOLVED (at least partially) for Linux/Unix/X11
by Frank's patch dated January 4, 2000 (see my comment on bug 2426) in
that the window title bar can correctly display non-ISO-8859-1 strings
as long as the locale under which window manager is running is the same
as the locale/encoding in which the page viewed in browser(i.e. title)
is encoded.  Unix/Linux/X11 version correctly passes along the page
title to window manager using the way specified in X11 ICCCM. By using
the corresponding spec for interclient communication under MacOS/Windows
might well solve the problem for MacOS/Windows.

   If you want the Japanese/Russian/Chinese title(encoded
in SJIS/ISO-2022-JP/EUC-JP,KOI8-R,Big5,EUC-CN/GB2312) to be correctly
rendered in the title bar(**realm of window manager**) of Korean window
manager, I guess you have to come up with a way to bypass the "normal"
mechanism by which window title bar is rendered. There could be a easy
way out provided that the window manager is running under a locale with
UTF-8 encoding and both window manager and Mozilla agree on the way to
exchange UTF-8 data. However, Linux doesn't yet have such a locale(while
Solaris and AIX have).

 In summary, this problem has to be split into two probelms:
  1. the case in which window manager locale/encoding is the same
     as the web page locale/encoding
  2. the case in which they're DIFFERENT.

 The first case is taken care of by Frank's patch for Unix/Linux/X11
version( The same is true of Netscape 4.x and 3.x) and could be
dealt with similarly in MacOS/MS-Windows.
Comment 32 nhottanscp 2000-04-04 16:26:53 PDT
*** Bug 34495 has been marked as a duplicate of this bug. ***
Comment 33 Peter Trudelle 2000-04-04 21:14:35 PDT
Mass moving M17 bugs to M18
Comment 34 Peter Trudelle 2000-05-25 16:52:40 PDT
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Comment 35 Peter Trudelle 2000-09-14 15:54:33 PDT
*** Bug 48169 has been marked as a duplicate of this bug. ***
Comment 36 Dan M 2000-10-25 10:22:28 PDT
*** Bug 56970 has been marked as a duplicate of this bug. ***
Comment 37 Dan M 2000-12-20 17:35:22 PST
*** Bug 61126 has been marked as a duplicate of this bug. ***
Comment 38 Dan Rosen 2001-04-10 13:54:32 PDT
*** Bug 75344 has been marked as a duplicate of this bug. ***
Comment 39 Ilya Konstantinov 2001-05-29 14:28:53 PDT
For X11, we can use the NET_WM standard
(http://www.freedesktop.org/standards/wm-spec/) to hint compliant window
managers of the correct UTF8_STRING for the window title. According to the
standard, a _NET_WM_NAME(UTF8_STRING) window property, when set, takes
percedence over the WM_NAME(STRING) property. The only window manager supporting
this currently is Kwin (KDE 2's WM), but it's adopted by both KDE and GTK+ 2.0.
A patch for mozilla/widget/src/gtk/nsWindow.cpp is attached.

Note: right-to-left language titles would appear reversed in Kwin since Kwin
wouldn't handle BiDi until ported to (upcoming) Qt 3.0. It's not up to Mozilla
to do BiDi of the window title, methinks.
Comment 40 Ilya Konstantinov 2001-05-29 14:31:29 PDT
Created attachment 36404 [details] [diff] [review]
Adds a _NET_WM_NAME(UTF8_STRING) property to windows on X11
Comment 41 Jacek Piskozub 2001-05-31 12:00:34 PDT
13 dups. Marking mostfreq.
Comment 42 Stuart Parmenter 2001-06-18 14:57:05 PDT
sure r=pavlov
Comment 43 Christopher Blizzard (:blizzard) 2001-06-19 07:26:26 PDT
+      char * utf8_title = NS_ConvertUCS2toUTF8(aTitle).get();
+

That's never released.  Should it be?
Comment 44 Dan M 2001-06-27 11:49:43 PDT
*** Bug 82950 has been marked as a duplicate of this bug. ***
Comment 45 Marc Loiselle 2001-06-30 10:03:35 PDT
The first 8 characters of an English title with length > 30 are replaced with 4
garbage characters using buildid 2001062821.

see http://www.mybc.com/ for an example

Window Manager is kde 2.1.1
Comment 46 Dan M 2001-06-30 18:07:31 PDT
Ilya's patch is in (28 June late afternoon). (Responding to Blizzard's comment 
above: the string isn't leaked; it's just a pointer to a stack-allocated string 
object's internal data.) And www.mybc.com behaves fine on my machine/build.
Comment 47 Boris Zbarsky [:bz] (still a bit busy) 2001-07-02 15:06:19 PDT
*** Bug 82252 has been marked as a duplicate of this bug. ***
Comment 48 Ilya Konstantinov 2001-07-03 16:14:14 PDT
Yes, there was a bug causing some garbage characters -- I should've tested it 
better! I did things the wrong way (e.g. grabbing the .data() once). Anyhow, 
it's all fixed now and should always work (tried on www.rambler.ru, 
www.yandex.ru, www.msn.co.il and my own test page). Attaching a diff -u 
against the CVS ...
Comment 49 Ilya Konstantinov 2001-07-03 16:16:31 PDT
Created attachment 41121 [details] [diff] [review]
A fix to my previous faulty patch.
Comment 50 Ilya Konstantinov 2001-07-03 16:28:37 PDT
With KDE2.2beta1 (with my latest Mozilla patch), I've noticed a random 
behavior from KDE's window manager Kwin, which adds a garbage character in 
it's own _NET_WM_VISIBLE_NAME property sometimes. From xprop -spy, I'm certain 
Mozilla assigns the right value, and KDE doesn't properly conform to the 
UTF8_STRING standard -- so I will take it as my mission to get that bug in KDE 
fixed. It's not a problem on Mozilla's side.
Comment 51 Martin Macok 2001-07-07 11:34:03 PDT
I tested this patch witch current trunk and it WFM.
Red Hat 7.1/KDE2.1.1
Comment 52 Christopher Blizzard (:blizzard) 2001-07-08 10:27:15 PDT
r=blizzard
Comment 53 Aleksey Nogin 2001-07-08 11:31:41 PDT
Please take a look at bug 89651 - could it be caused by these patches?
Comment 54 Christopher Blizzard (:blizzard) 2001-07-08 12:42:02 PDT
It's very possible that bug is the same as this one.
Comment 55 Francisco León 2001-07-08 15:13:47 PDT
I duped my bug 89651 against bug 88384
It's really ugly to see almost all titles in windows being screwed up
I am using kde 2.1.1, xfree 4.1.0 
Is this one trunk-only? I think this is a blocker of the 0.9.3 release. What
will users think of the product when they see those chars?


Comment 56 Francisco León 2001-07-08 15:41:40 PDT
I just submitted to KDE this problem
Please wait until i get a response for them (i invited them in here too)
Comment 57 jag (Peter Annema) 2001-07-08 19:43:39 PDT
Instead of |strlen(utf8_title.get())| you can just do |utf8_title.Length()|. The
length of an nsCString is stored in it, and should save you having to scan for
|0| each time.
Comment 58 Ilya Konstantinov 2001-07-11 07:14:49 PDT
Created attachment 41935 [details] [diff] [review]
The same patch, with jag's suggestion. Tested against fixed kwin (as would come with KDE 2.2).
Comment 59 jag (Peter Annema) 2001-07-11 07:26:39 PDT
r=jag
Comment 60 Christopher Blizzard (:blizzard) 2001-07-12 13:26:36 PDT
sr=blizzard
Comment 61 jag (Peter Annema) 2001-07-13 01:56:06 PDT
Patch checked in.
Comment 62 Jungshik Shin 2001-07-23 15:51:14 PDT
I'm wodnering if anybody has paid attention to the following
article found in MSDN archive :

   http://www.microsoft.com/msj/1198/multilang/multilang.html

   (Supporting Multilanguage Text Layout and complex Scripts with Windows NT 
5.0) 

I guess many have, but seem to have forgotten
to bring it up here or haven't brought up here because it's not applicable
to Mozilla for some reason unknown to me. Anyway, just in case it hasn't
caught attention of anyone involved with this bug, I'm adding this comment.

 Around the end of the article, four strategies are 
presented to support multilingual applications for both Windows 9x/ME 
and Windows NT4/2000. It seems like the fourth approach might as well
be considered for use in Mozilla. Below is an excerpt from the article:

MSDN> Strategy 4 Detect the system and explicitly call the W APIs for WindowsNT 
MSDN>and the A routines for Windows 95 and Windows 98. The application 
MSDN> registers itself as a Unicode application on Windows NT and as an ANSI 
MSDN> application on Windows 95 and Windows 98. 
MSDN> The easiest way to implement this approach is to write a set of 
MSDN> functions, say U routines, that parallel the Win32 W and A routines. Your 
MSDN> application first calls GetVersionEx to detect the system, and stores 
MSDN> that information into a global variable: 

  Implementing CreateWindowExU and CreateWindowU the way described above
might(or might not) be easier than incorporating  jilu's approach ftang dug up 
(implementing Mozilla's own drawing routine). Last week on Unicode mailing 
list, somebody
asked a question related to this issue and one of answers was to use
CreateWindowExW (on Win2k/NT4). Just FYI, I put it up at 
http://www.jshin.net/~jungshik/i18n/mswintitle.html
Comment 63 Jungshik Shin 2001-07-23 16:03:12 PDT
I'm sorry to bother again. In my previous comment, I forgot that Mozilla needs
to display strings (not supported by the present locale) in the title
bar both under Windows 9x/ME and Windows NT4/2k. The approach I suggested
solves the problem (at both levels outlined by ftang in his
comment back in 1999) for Windows NT4/2k  but doesn't solve the 2nd
level problem (that is displaying Japanese string in French Windows) for
Win 9x/ME. I guess what MS IE 5.x does is follow the strategy 4 (in MSDN
article I quoted in my previous article) so that it can display Japanese 
string in the window
title bar in French Windows NT4/2k while it cannot display Japanese string
in French Windows 9x/ME (thus, it displays the URL of the page instead).

  If the goal is to display Japanese string in French Windows 9x/ME as well
as in French Windows 2k/NT4, I think adopting jilu's code from NS 4.x into
Mozilla is the way to go. If Mozilla can be content with doing what MS IE 5.x
does, strategy 4 could be easier (but I'm not sure).  
Comment 64 Greg K. 2001-08-08 18:53:04 PDT
FYI, there are bugs filed about this problem on specific OS's...bug 74753
(Linux), bug 36689 (Mac OS 8/9), and bug 92503 (Mac OS X). Bug 92503 (Mac OS X)
appears to have a fix-in-hand.
Comment 65 Christian Reis 2001-09-03 12:26:15 PDT
Changing summary to include titlebar for easy searching.
Comment 66 John Morrison 2001-10-21 17:50:24 PDT
*** Bug 105921 has been marked as a duplicate of this bug. ***
Comment 67 James Cox 2001-11-04 12:04:26 PST
A number of other bugs that *have* been worked on are similar to this, so to
avoid duplication, it's worth merging these together.

The issue occurs with all non-english text, where you get ?????.??? type titles.
I wonder what happens, though, if moz renders the title correctly, but you
haven't got the appropriate character set installed with your OS? 

anyhow. it's still open.
Comment 68 James Cox 2001-11-04 12:05:12 PST
*** Bug 61676 has been marked as a duplicate of this bug. ***
Comment 69 James Cox 2001-11-04 12:05:58 PST
*** Bug 108418 has been marked as a duplicate of this bug. ***
Comment 70 石庭豐 (Seak, Teng-Fong) 2001-11-04 12:49:31 PST
When the OS doesn't have the appropriate font for the title (as well as the
webpage), maybe Mozilla could display a dialog/warning window saying the page
won't be displayed correctly, and maybe suggests an URL/method to user to get
the font.
Comment 71 Olav Vitters 2001-11-11 06:14:21 PST
*** Bug 109599 has been marked as a duplicate of this bug. ***
Comment 72 Michael Entin 2001-11-22 02:16:53 PST
Interesting, but Mozilla 0.9.6 (20011120)is broken even on Windows XP, when all
Unicode fonts are present. I see lots of '????' in title when I go to
http://www.computerra.ru/.
Mozilla 0.9.5 did not have this problem (at least on Windows 2000).
Comment 73 石庭豐 (Seak, Teng-Fong) 2001-11-22 02:28:19 PST
Is that Win XP Pro or Win XP Home?  People always forget that there're two Win
XP.  Pro is in WinNT series, whereas Home is in Win95/98/ME series.
I don't have WinXP Home, but I would tend to suspect its Unicode support isn't
as complete as in Win2k/XP Pro.
Comment 74 Jungshik Shin 2001-11-22 08:03:13 PST
It could be due to the difference between Win XP home
and Win XP Pro, but more likely is that on Win2k, you
set the default language (in Control Panel - Regional
Options) to Russian while on Win XP, you didn't.

I just sorta confirmed my suspicion. When I tried
Mozilla 0.9.5 under Win2k with the default language
set to English, the title bar has "?" in place
of Cyrillic letters when I visited www.computera.ru.
However, after setting my default language (system locale) to
Russian (go to Control Panel | Regional
Options and press the button 'Set default' and
choose 'Russian') and rebooting Win2k(you have to reboot
after changing the default language), Cyrillic letters
were displayed perfectly fine under Win2k + Mozilla 0.9.5
 
What  people (new to this bug) keep forgetting or don't know is
that there are two facets to this bug (this has been mentioned
a couple of times before in this thread)

  1. not being able to display non-English characters 
     even when Mozilla is running under the locale which
     supports those characters. That is, under Russian
     Windows-whatever (9x/ME/NT4/2k/XP)(or Unix/X11,
     MacOS), Russian characters
     should be rendered correctly in the title bar.
  
  2. not being able to display characters *outside* the
     character repertoire of the current locale.
     That is, Russian characters are not rendered under
     English/French/Chinese/Japanese/German Windows
     or Unix/X11 with E/F/C/J/G locale.

I believe the first bug has been fixed for a long time
(in Netscape 3.x) and
what we have been really concerned with is the second one.
Therefore, I think the summary line should be changed
to something like this:

  chars outside the char. repetoire of the current locale
  NOT rendered in title bar

Please, note that MS IE certainly solved the second problem
as well. No matter what language version of
Win2k you use or what default language you choose,
the title bar is rendered correctly for all the scripts and
languages supported by Win 2k (and XP). Of course,
this is not the case under Win 9x/ME. Therefore, our
target on Windows platform for this bug is to get
the second bug fixed for WinNT4/2k/XP  (XP Pro only if
XP Home and XP Pro are different in terms of Unicode
support).
Comment 75 Jungshik Shin 2001-11-22 10:03:50 PST
I asked  Unicode mailing list if there's any
difference between Win XP Home and Win XP Pro
in terms of Unicode support and got the following
reply, which agrees with what I had thought before (i.e.
both XP Home and XP Pro are descendants of NT. MS attempted
the unification of their two lineages of Windows -
9x and NT - when releasing Win2k but failed. However, they finally
did it in XP):

-------
All versions of XP are derived from NT.  
The differences between Home and Pro versions are target markets and price.
The Home version cannot be centrally managed as a part of a domain and IIRC
it doesn't support multiple processors, making it unsuitable most companies. 
--------
Comment 76 Ilya Konstantinov 2001-11-22 11:00:28 PST
I have zero exprience coding for Windows, but according to what I've found on
MSDN, WinNT supports BOOL SetWindowTextW(HWND hWnd, LPCTSTR lpString) natively
while Win9x/ME requires something called "Microsoft Layer for Unicode" to be
installed to be able to import this function from a DLL. Since we won't
redistribute this upgrade to all users, I guess we'll only use SetwindowTextW on
WinNT (and XP).

See:
http://msdn.microsoft.com/library/en-us/winui/windows_07w4.asp
http://msdn.microsoft.com/library/en-us/win32/unilayer_4wj7.asp
Comment 77 Jungshik Shin 2001-11-22 14:47:33 PST
Could someone tell me how MS-Windows binary is compiled in terms
of Unicode support? I'm wondering how Mozilla deals with 
A and W versions of Win32 API calls. In other words, which of
the four strategies outlined in the following article used
to make a single binary work with both Win 9x/ME and NT/2k/XP? 

 http://www.microsoft.com/msj/1198/multilang/multilang.htm

(I mentioned this article in my comment in July 2001, but
there was a spurrious 'l' at the end of the URL)
I thought Mozilla uses strategy #4 and has a kind of wrapper to detect the OS
it's running under (whether
it's Win9x/ME or Win NT4/2k/XP) and invokes A or W version
accordingly. However, a quick search with lxr couldn't lead
me to such a wrapper.

  Having dug up James Toder's patch (checked in October 1999
: news://news.mozilla.org/19990920123309.2772.rocketmail@web1604.mail.yahoo.com
) 
I realized that Mozilla uses strategy #3 (compiling Mozilla
as ANSI application with Unicode used internally but converted
to the current codepage before invoking 'A' version of Win32 calls)

  This means that CreateWindowEx() in Mozilla is mapped
to CreateWindowExA() instead of CreateWindowExW(). 
According to what I gather a few months ago
on the Unicode mailing list (see
http://www.jshin.net/~jungshik/i18n/mswintitle.html),
calling SetWindowTextW() for a window created with CreateWindowExA()
would not work as intended. By the same token,  I guess
SendMessageW() instead of SendMessage() (which is actually
SendMessageA() in ANSI applications) wouldn't work, either.

 Adopting strategy #1 (compiling as a pure
Unicode application  and bundling Unicode layer
for Win9x/ME) in the MSDN article aforementioned
appears to be nice, but I guess it's not plausible at this point
(there could be hundreds of places requiring fixes if
we suddenly switch from 'A' calls to 'W' calls)
Moreover, bundling Microsoft layer for Unicode may not be
compatible with various licenses Mozilla is licensed under.

I'll try to find out if there's a way around 
(Like  Ilya, I have no experience with Windows programming,
but ....). Of course,
we have jilu's routines.
Comment 78 Jungshik Shin 2001-11-22 15:20:26 PST
What about this ? Just as a proof of the concept(?)

1. Determine whether the OS is Win 9x/ME or Win NT4/2k/XP
(perhaps with GetVersionEx()) and set the flag g_IsWindowsNT (global)
  during the start-up. 

2. In widget/src/nsWindow.cpp

   if g_IsWindowsNT
      CreateWindowExW()
   else 
      CreateWindowExA()
   ....
   if g_IsWindowsNT
       use SetWindowTextW()
   else
       use James Toder's routine as it is now

Again, I'm just thinking loud as someone with
zero-experience with Windows programming
and my idea may look crazy
Comment 79 Jungshik Shin 2001-11-25 14:38:17 PST
Created attachment 59123 [details] [diff] [review]
a patch for Windows NT4/2k/XP 

I've just made this patch to solve what Frank calls
the second-level problem. It is  based on MSDN documents
on GetVersionEx() and  SendMessage() (I have zero experience
with MS-Windows programming) and  
two-year old patch for what Frank called the first-level problem.
I also refered to nsCollationWin.* to figure out
what's necessary to  call A or W
API functions depending on the version of MS-Windows (9x/ME vs
NT 4/2k/XP).

Since I don't have Visual C++ for MS Windows, I'm not able
to test it. It may not even get compiled let alone fixing
the bug. It would be nice if it's tested (or taken a look at).
Comment 80 timeless 2001-11-25 22:56:46 PST
i'd rather that we try to use the W function if it's available instead of when 
we think it will be available.
GetProcAddress 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/dll_0f
8z.asp
is what i was thinking of, and it all goes back to the Microsoft Layer for 
Unicode...

still this looks like a good start
Comment 81 Jungshik Shin 2001-11-26 03:47:14 PST
Thank you for looking at my patch.

I'm not sure whether GetProcAddress() gives us any advantage in this
particular case.  Below is my thought (which may not
be right) based on MSDN articles.

W API functions are guaranteed to be available in Win NT 4/2k/XP. By not
using GetProcAddress() and using GetVersionEx() to check the availability
of W API functions, we only miss the case where MS layer for Unicode
is installed under Win 9x/ME.  However, MS layer for Unicode cannot do
anything that cannot be done with A API functions in Windows 9x/ME as far
as I understand. It just makes W API functions available in Win 9X/ME,
but W API functions in Win 9x/ME get translated, by MS layer for Unicode,
to A API functions which are limited to the repertoire of the locale. That
is,  under French Windows 9x/ME, calling W API functions with MS layer for
Unicode in the hope that Chinese title gets rendered correctly is futile.

Therefore, unless something like jilu's patch (rendering window title
on our own instead of relying on OS APIs) is done, I guess we cannot
render Chinese title under French Windows 9x/ME.

If my patch works as intended, I believe Mozilla's behavior matches that
of MS IE 5.x under both MS Win NT4/2k/XP and Win 9x/ME except that under
the latter MS IE 5.x puts the URL instead of question marks in place of
unrenderable characters.
Comment 82 石庭豐 (Seak, Teng-Fong) 2001-11-26 04:02:11 PST
Jungshik Shin,
  Yes, Win9x/ME should be treated differently from WinNT4/2k.  Actually, I've
reported this in April:
http://bugzilla.mozilla.org/show_bug.cgi?id=75344
but that bug was marked as a dup of this one and the discussion just ended.
Comment 83 timeless 2001-11-26 04:13:34 PST
one thing it gives us is a bit of correctness. if WINE or something 
similar decides to implement a W version of this function for a system that 
doesn't call itself NT then you'll do the wrong thing.

your code is akin to using: if (navigator.userAgent.match(/4/)>0)
instead of using: if (document.layers) when trying to decide if a browser has 
layers.
Comment 84 Jungshik Shin 2001-11-26 07:24:26 PST
timeless,

Thank you for clarification. I didn't think about WINE or other
implementation of Windows API.  Your point was well taken.

There are several other places GetVersionEx() is used to determine the
availability of W API functions (use lxr and search for GetVersionEx
or W_API). If you want to fix all of them, I guess it's a good idea  to
raise that issue in a separate bug so that they can be fixed everywhere
(instead of not just here)

I'm also concerned about the implication of the following statement:

  Because the program uses run-time dynamic linking, you should not link
  with the import library when creating the program module.

at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/dll_69nr.asp

IMHO, here we'd rather concentrate on getting things done the way they're
done in other places of Mozilla than try to raise the bar for correctness.

BTW, when calling CreateWindowW() in my patch, the third parameter
' "" ' should be LPCWSTR so that I guess ' "" ' should be
' (LPCWSTR) L"" ' (or just ' L"" ' )
Comment 85 Jungshik Shin 2001-11-27 21:31:34 PST
Created attachment 59481 [details] [diff] [review]
a new patch(bas. the same) for WIn2k/NT4/XP

A slightly modified patch which I actually
applied to get the whole thing compiled
with VC++. Unfortunately, it does not
solve the problem. I confirmed on Win2k that
W version of SendMessage and CreateWindow
are called with the page title
in LWCWSTR (PRUnichar*), but it didn't
work as intended. (the result is exactly
the same without the patch on Win 2k).
Comment 86 Simon Montagu :smontagu 2001-12-11 21:54:48 PST
*** Bug 114792 has been marked as a duplicate of this bug. ***
Comment 87 Jean-Marc Desperrier 2002-01-29 05:59:22 PST
I've seen the following remarks that comes from a contributor to
news://msnews.microsoft.com/microsoft.public.win32.programmer.international

I don't know if it makes sense, but if it's true, it may explain why the latest
patch does not solve the problem.

>>>>>>>>>>>

I think, Netscape asks OS to use "MS Sans Serif"
to draw the title (which is not multilingual, it's single code page
font), while Windows 2000, _unlike NT 4.0_ has new system font -
"Microsoft Sans Serif" which is Unicode font (contains Hebrew).

Probably this is why my IE 5.5 works differently under NT 4.0 and 2000 -
in IE code, unlike Netscape, they did *not* use hard-coded name
"MS Sans Serif" and use, instead, MS generic name for system font -
therefore under Windows 2000 IE 5.5 uses new, Unicode
"Microsoft Sans Serif" that contains Cyrillic!
Comment 88 odd@findus.dhs.org 2002-01-31 06:07:06 PST
This is on GNU/Linux, Mozilla nightly Jan 31. LC* settings are as follows:

declare -x LC_ALL="POSIX".

The problem is with http://overosa.dhs.org/index.html

the title is written like this in the source: "&ouml;ver&ouml;sa" -- which is
shown as "?ver?sa" in the Mozilla title bar. In the location field history/tab
field where the Title is shown, it is shown correctly as "överösa". Font for
everything is Lucida, shiped with XFree86 4.2.0
Comment 89 odd@findus.dhs.org 2002-01-31 06:43:23 PST
Followup to my last comment:

When setting LC_ALL to sv_SE, and LANG to sv_SE, the title is displayed correctly.

Just setting LC_MESSAGES=sv_SE does not seem to be enough.
Comment 90 Jungshik Shin 2002-02-05 19:42:52 PST
It's natural that just setting LC_MESSAGES without setting
LC_CTYPE (or LANG/LC_ALL) doesn't work. It's LC_CTYPE that determines
the way Window manager and Mozilla communicates. Simple cases
(displaying Swedish title under Swedish locale) 
like yours was  taken care of by Mozilla developers a long time ago.
The issue here is to make Swedish title displayed correctly
under non-Swedish locales such as Japanese and Chinese locales.
Even that now works with KDE(newer version) under Linux although
that's not the case yet in MS-Windows.
Comment 91 Olivier Cahagne 2002-02-28 00:10:34 PST
*** Bug 128174 has been marked as a duplicate of this bug. ***
Comment 92 石庭豐 (Seak, Teng-Fong) 2002-03-05 01:45:50 PST
 Re: comment #87

> I think, Netscape asks OS to use "MS Sans Serif"
> to draw the title (which is not multilingual, it's single code page
> font), while Windows 2000, _unlike NT 4.0_ has new system font -
> "Microsoft Sans Serif" which is Unicode font (contains Hebrew).

I don't think this would work for Win2k either for all languages :
1) "Sans Serif" or any other like "Times" or "Arial" as a font name is
meaningless for other languages such like CJK.
2) It seems that when rendering Unicode strings, Windows tries to concatenate
substrings from different fonts.  I think this is the best way to go for Mozilla
to display Window title string.  In this way, there's no need to think about
whether it's "MS Sans Serif" or "Microsoft Sans Serif".  FYI, the size of "Sans
Serif" is too small to contain all Unicode characters.
Comment 93 Sebastian Biallas 2002-03-17 08:04:32 PST
*** Bug 131558 has been marked as a duplicate of this bug. ***
Comment 94 Boris Zbarsky [:bz] (still a bit busy) 2002-03-18 18:25:05 PST
*** Bug 131868 has been marked as a duplicate of this bug. ***
Comment 95 Jungshik Shin 2002-03-22 11:05:07 PST
Created attachment 75613 [details] [diff] [review]
a new patch for Win2k/NT/XP that does work

After reading Frank's comment on bug 97671 (basically the same bug as this
one),
I gave it yet another shot at fixing this bug under Win 2k/NT/XP.
This is certainly not the most efficient (performance-wise) and the prettiest
patch, but I just want this to be regarded as a proof of concept from which
we can start toward a better fix.  Anyway, it works !!

With the default locale set to Korean under English Windows 2000, I was able
to see a lot of simplified Chinese characters (which are NOT available in
X-Windows-949/CP949 for Korean) in the title bar while browsing
http://cn.yahoo.com
or http://home.netscape.com/zh/cn.

I'd be glad to hear feedback, positive or negative, for this patch. 

BTW, applying this patch, Mozilla will be on par with MS IE 5.x/6.x in terms
of being able to display characters NOT native to the present locale
in the title bar. MS IE 5.x/6.x can do that under Win NT/2k/XP but
CANNOT under Win 9x/ME.
Comment 96 Roy Yokoyama 2002-03-22 11:35:54 PST
Jungshik: 
Few months back, I worked on 
compile moz with -DUNICODE flag; but 
it just had soooooo many errors and 
warnings to make moz a true Unicode app.

I started to realize that instead of 
bitting a big fish, we should start with
smaller scope.   (ie call _::RegisterClassW()_ and
selectively call W-APIs)   

Your approach is exactly what I wanted to do.
I am glad it works. :)  
I can't work on this until post moz 1.0; but
we should definitely pursue this approach.

Thanks again.
Comment 97 Jungshik Shin 2002-03-22 13:09:04 PST
Roy,

Thank you for your positive response. I'm also glad that
we approached the problem exactly the same way. I almost
gave up when I found more and more API calls(A vs W) to be selected
depending on the platform (9x/ME vs NT/2k/XP in nsWindow.cpp),
but fortunately that 'spree' ended without going much farther.

Now as to what to do with this now, I'm not sure. Obviously
you're too busy preparing for 1.0 to work on this. Perhaps,
it may be also a bit risky(my experience with Win32 programming
is limited and I definitely need Win32 experts like you to
thoroughly review and polish up my code) to put this in when 1.0 
deadline is approaching. 
On the other hand, it makes me a bit uncomfortable to see this bug
left unfixed in 1.0 because there are so many duplicates of 
this bug (I guess this is one of the most frequently reported 
and the longest standing bugs in i18n) and Mozilla's archrival 
MS IE does  it right. 

Could you think of anyone other than you, within or without 
Netscape, who can pitch in for reviewing and refining my patch 
so that it can make itself in 1.0? 

Sorry for the 'babbling'(?), but I feel 'a bit attached to'
this bug and  like to get this taken care of in 1.0 _if possible_. 

Comment 98 Aaron Kaluszka 2002-04-05 12:06:49 PST
*** Bug 135718 has been marked as a duplicate of this bug. ***
Comment 99 Roy Yokoyama 2002-04-05 13:08:16 PST
Man, here it comes again.  Duplicate of this bug.
I am getting tired of getting the duplicate every few weeks.
Let me try if I can put this in moz 1.0

Making moz milestone to 1.0
Comment 100 Jungshik Shin 2002-04-05 16:29:24 PST
Roy,
Great to hear that you want to put this in for moz1.0 :-)
Have you tried my patch on your build? My build works fine as far as I can
tell, but who knows? I may have missed a couple of spots
where I should invoke W API calls if available. 
Perhaps, I've gotta put up my build somewhere so that those interested 
can play with it because I don't spend much time under MS-Windows. 
Do you think it's a good idea? 
Comment 101 R.K.Aa. 2002-04-06 12:41:46 PST
*** Bug 135908 has been marked as a duplicate of this bug. ***
Comment 102 石庭豐 (Seak, Teng-Fong) 2002-04-07 05:54:35 PDT
Since there are W and A API's, isn't it better to compile two different versions
for Windows, ie Win9x/ME and WinNT4/2k/XP ?  We could, at the same time, include
some optimal codes for just WinNT4/2k/XP platforms!  Furthermore, by having two
separate versions, those who want the stable one can always download Win9x/ME
version since this works in WinNT/2k/XP as well, whereas the other version is
left to those other more courageous users :)
Comment 103 timeless 2002-04-07 09:23:36 PDT
seak, no. i'd much prefer for us to go strictly to the W form and offer the 
microsoft unicode wrapper for 9x consumers.  if there arewany W api's that we 
need which the wrapper doesn't provide we can role our own fallbacks.
Comment 104 Jungshik Shin 2002-04-07 11:20:46 PDT
> seak, no. i'd much prefer for us to go strictly to the W form and offer the
> microsoft unicode wrapper for 9x consumers.  if there arewany W api's that we
> need which the wrapper doesn't provide we can role our own fallbacks.

  In the long run, I fully agree with you that we have to do
that.  However, as Roy noted, it's not so easy to do that at the moment
because there are so many places in Mozilla code that depend on A API's
behavior (e.g.  assuming LPTSTR is 'char *', which doesn't hold true as
soon as we define 'UNICODE' and W APIs are used. It would have been great
if Mozilla had been a 'Unicode application' from the beginning, but we
can't do anything about things in the past .... ). A short term solution is,
I believe, to selectively use W APIs as necessary.

  Perhaps, a branch has to be made for Mozilla as a 'Unicode application'...
Comment 105 Jungshik Shin 2002-04-07 15:22:17 PDT
Created attachment 78132 [details]
stack backtrace : access violation error  with my patch

I ran more extensive test with attachment 75613 [details] [diff] [review] applied to the latest trunk
and found that it crashed at pages such as http://www.hani.co.kr
and http://www.lemond.fr and sometimes http://www.yahoo.co.jp (not always
in the last case) although Mozilla could display characters outside
the repertoire of the present locale codepage in the title bar. 

I tried to figure out the cause, but couldn't. I also made more extensive
replacements
of  A API calls with platform-dependent  W/A API calls in nsWindow.cpp and
nsToolkit.cpp than in bug 75613, but that didn't make any difference.

Attached is stack backtrace I obtained from my debug build
with attachment 75613 [details] [diff] [review] applied just in case more
experienced mozilla hackers and Win32 programmers can figure out the
cause of the crash.

BTW, I couldn't make an optimized build (make looked for xp_core.h,
which appears to have gone away a long time ago)
Comment 106 Frank Tang 2002-04-08 14:24:20 PDT
I think this is too risky for nsbeta1, nsbeta1- this. Jungshik Shin and Roy,
please keep work on this but plan to land after we branch so this won't impact
the coming release. I would love to see this in the first thing after m1.0

work around is using "tab" instead of "window"
Comment 107 Jungshik Shin 2002-04-08 16:42:39 PDT
Frank,
Thank you for looking into this.
I agree with you that this is too risky as it is now and it seems reasonable
to push this after m1.0 
Comment 108 Vadim Berezniker 2002-04-10 19:43:03 PDT
*** Bug 136683 has been marked as a duplicate of this bug. ***
Comment 109 R.K.Aa. 2002-04-12 13:26:34 PDT
*** Bug 137143 has been marked as a duplicate of this bug. ***
Comment 110 Christian :Biesinger (don't email me, ping me on IRC) 2002-04-16 06:25:45 PDT
Comment on attachment 75613 [details] [diff] [review]
a new patch for Win2k/NT/XP that does work

+//  virtual LPCTSTR	     WindowClass();
+//  virtual LPCTSTR	     WindowPopupClass();

you should delete these functions rather than commenting them out

+  if ( ::IsWindowUnicode(mWnd) ) 
+      fputs ("Current window is Unicode window\n",stderr);
+  else 
+      fputs ("Current window is ANSI window\n",stderr);

Why not use the IS_UNICODE macro?

and, you shouldn't unconditionally write data to stderr... can you wrap that in
#ifdef DEBUG  or use PR_LOG?
Comment 111 Jungshik Shin 2002-04-16 07:12:15 PDT
Christian,
Thank you for reviewing my patch.

I agree with you on both issues(using IS_UNICODE macro
and #define DEBUG_jungshik and removing unnnecessary commented-out-lines). I
thought I removed all those debug print-out's when I uploaded attachement 75613,
but somehow I didn't. 
Anyway, my patch,
as it stands, cannot go in because there's a serious problem as noted
in comment #105. It was not meant to be final but for others with more
experience in Win32 programming to review and comment on. I've made
some more changes since, but that hasn't helped me removing the problem
I wrote about in comment #105.
Comment 112 Yuying Long 2002-04-23 15:37:41 PDT
*** Bug 138916 has been marked as a duplicate of this bug. ***
Comment 113 Roy Yokoyama 2002-04-25 19:11:42 PDT
Unfortunately not going into moz 1.0
Comment 114 Shoshannah Forbes 2002-04-26 03:47:36 PDT
this iis bad, very bad, since corrently in the latest mac builds, there has been a 
regression and hebrew titles do not disply in tab titles either- there is no way to 
know or see a hebrew title when using moz on mac.
Comment 115 Roy Yokoyama 2002-05-21 10:53:09 PDT
*** Bug 143563 has been marked as a duplicate of this bug. ***
Comment 116 Roy Yokoyama 2002-05-21 14:02:24 PDT
from comment #114
>know or see a hebrew title when using moz on mac.
simon: Were we able to support hebrew title in Mac before?  I know 
       japanese works on MacOSX.  Has it broken recently?
Comment 117 Simon Montagu :smontagu 2002-05-21 14:14:14 PDT
I have no direct experience, and maybe Shosh can amplify, but my understanding
is that Hebrew titles work on Mac OSX but not on OS 8/9
Comment 118 Shoshannah Forbes 2002-05-22 03:37:16 PDT
>but my understanding
>is that Hebrew titles work on Mac OSX but not on OS 8/9
Correct. this is true for tab labels as well as the window title bar itself
Comment 119 Shoshannah Forbes 2002-05-22 06:30:15 PDT
*** Bug 119881 has been marked as a duplicate of this bug. ***
Comment 120 Mark Kaplun 2002-06-05 02:40:44 PDT
IMHO this bug should have an higher severity. It realy should be fixed for
mozilla 1.0 (and netscape 7.0) in order to make them usable for non english
speakers.

I don't see how you are going to convince web developers and web users to switch
to mozilla/netscape when they do not support all the features available at IE
(windows platforms ofcourse).

More important then the title itself (I guess many people can work with ??? as
title if they must) is the feeling that even 1.0 is not a finished product, and
a commercial grade software, when it has such a main stream bug. 

I am using RC3 on XP.

More sites for refference:
hebrew - http://www.haaretz.co.il/
arabic - http://www.naseej.com.sa/StaticPages/main/about/about1_1_e.html
Comment 121 石庭豐 (Seak, Teng-Fong) 2002-06-06 07:50:30 PDT
I agree too; those ? ? ? are really ugly!

Those two URL in comment #76 can't be found anymore, but I've found another one
related to developping Unicode App for 9x platform.
timeless, is this the "microsoft unicode wrapper" that you talked about in
comment #103 ?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag01/html/MSLU.asp

But if time is too short to use the MSLU before Mozilla 1.0 release, I would
suggest that Mozilla display just the URL in the title bar, just like how IE
does in Win9x platforms.

For Unicode platforms, maybe Mozilla can do the same for the time being?
Comment 122 Jungshik Shin 2002-06-06 08:36:13 PDT
Using MS layer for Unicode is not a viable option at the moment as Roy
mentioned before.  That requires converting Mozilla (for MS-Windows)
to a Unicode application, which is not so easy.  As Roy and I wrote,
selective use of W API calls is much more viable solution than that. My
attempt to do that was partially successful (in that my build with that
patch is able to display characters outside the repertoire of the present
'code page' in the title bar), but it still dumps core in some cases.

Now that Mozilla 1.0 has been released, I guess it's time to
work on this again.
Comment 123 Roy Yokoyama 2002-06-06 09:27:57 PDT
Created attachment 86614 [details] [diff] [review]
revising jshin's patch

I had little time to play with your idea and I did little clean up.
Unfortunately, I am getting link error for from nsWindowFactory saying 
missing WindowClass() WindowPopupClass().  I am hoping someone can shed some
light on this error.
Comment 124 Roy Yokoyama 2002-06-06 09:28:12 PDT
Created attachment 86615 [details] [diff] [review]
revising jshin's patch

I had little time to play with your idea and I did little clean up.
Unfortunately, I am getting link error from nsWindowFactory saying 
missing WindowClass() WindowPopupClass().  I am hoping someone can shed some
light on this error.
Comment 125 Roy Yokoyama 2002-06-06 10:15:14 PDT
Created attachment 86631 [details] [diff] [review]
Compiled :)

it needed to have -DMOZ_UNICODE in /src/build/makefile.win
Comment 126 Roy Yokoyama 2002-06-06 10:31:50 PDT
yap. the patch works.  I can display Korean title in WindowsXP-SC with
no violation errors. However, we need more testing.
Comment 127 Shoshannah Forbes 2002-06-07 01:56:46 PDT
Is this going to be a windows only fix? Should I re-open Bug 119881 (a mac bug, 
marked right now as a dup of this one)?
Comment 128 Wesha 2002-06-07 08:31:35 PDT
Build 2002060704 / Win2000 : question marks instead of Russian characters still.
Didn't the patch made it to the trunk?
Comment 129 Roy Yokoyama 2002-06-07 09:54:10 PDT
>question marks instead of Russian characters still.
>Didn't the patch made it to the trunk?
No, no patch was checked into the trunk.  I tested my patch on
Win2000-Ja and it displayed russian, korean, french, hebrew and arabic correctly.
(note. to display bidi text in correct order, we needed to enable bidi
       from windows control panel.  However, moz is parity with IE.)

>119881
If 119881 is mac specific, then please reopen 119881.  
Comment 130 Wesha 2002-06-07 10:03:44 PDT
OK, will try it on 20020608 tomorrow. 
Comment 131 Roy Yokoyama 2002-06-07 10:04:13 PDT
Created attachment 86811 [details] [diff] [review]
define MOZ_UNICODE environment variable

Define MOZ_UNICODE as environment variable so that we can co-exist 
with the current moz-win32 build.

To build moz-unicode:
- define MOZ_UNICODE environment variable by SET MOZ_UNICODE=1
- re-build widget module after clobbering the module
Comment 132 Roy Yokoyama 2002-06-07 10:21:22 PDT
Created attachment 86814 [details] [diff] [review]
Oops, forgot to include nsWindowAPI.h

Same as above except to include nsWindowAPI.h
Comment 133 Roy Yokoyama 2002-06-07 10:23:55 PDT
Created attachment 86815 [details] [diff] [review]
Removing un-necessary part

shhh,  I guess I am little excited.   Here is the latest.
Comment 134 Roy Yokoyama 2002-06-07 10:49:22 PDT
Created attachment 86820 [details] [diff] [review]
Ahhhh  wrong DEFINES
Comment 135 Jungshik Shin 2002-06-07 23:21:30 PDT
Roy,

I've just tried your patch (not the newest one but attachment 86631 [details] [diff] [review].
Is there any difference between them other than Makefile tweaking
for co-existence of MOZ_UNICODE build and non-MOZ_UNICODE build? ),
I got exactly the same access violation
(according to the stack trace in VC++ 6.0) 
at http://www.hani.co.kr, which is among sites where I got
access violation with my patch. (see my comment 105)
I applied your patch to the trunk (fetched afresh off
the cvs last night). I had to hand-edit it a bit because
the trunk and Mozilla 1.0 branch are different.

Have you treid http://www.hani.co.kr and http://www.lemonde.fr
with your patch applied?  My test environment is
Korean locale + English Windows 2k. 
 
Comment 136 石庭豐 (Seak, Teng-Fong) 2002-06-08 04:53:46 PDT
Re comment #122:
Yeah, I still remember that you had insisted several times that Mozilla isn't a
Unicode application.  Mmmmm ......  I didn't think more about this, but now that
I rethink about it, I have a question:
do you mean that Mozilla wasn't programmed as a Unicode application at the very
beginning ?  Or do you mean some component aren't Unicode compliant?

I'm also think if it isn't possible to make a general call or a general "bug" to
every component maintainer to check their codes.  Eg, file a "bug" for every
component as a reminder to its maintainer so as to check if his/her code is
Unicode compliant, and file one more "bug" and mark it as dependent to all others.
Comment 137 Jungshik Shin 2002-06-08 05:30:59 PDT
> do you mean that Mozilla wasn't programmed as a Unicode application at the 
> very beginning ?  

  Have you ever looked at my or Roy's patch? 

In Win32 programming, a 'Unicode application' is an application
written and compiled with 'UNICODE' defined. When it's defined,
all generic Win32 API calls (which are NOT explicitly specified as A API
calls)   default to W API calls. W API calls are not available
on Win9x/ME by default, but MS Layer for Unicode  translates
them to locale-dependent/codepage-dependent A API calls under(and only under)
Win 9x/ME. Therefore, a single Unicode application can be written
which works both under Win9x/ME and Win NT/2k/XP. 

However, this does not work for Mozilla at the moment.
As I and Roy mentioned **multiple times** __here__, on numerous 
places in Mozilla source, it's  assumed that generic Win32 API calls are A API 
calls. Sometimes A and W API calls have exactly the same arguments (in
terms of the number and  type of arguments, return type, etc). Unfortunately,
often times, they're **different** in return type and type of arguments.
(see Roy's patch and look into nsWindowAPI.h file and you'll see
what I mean) Because it's assumed that all generic(without
'A' or 'W' attached at the end) Win32 API calls are A API calls  in Mozilla 
source, just defining 'UNICODE' and turning all Win32 API calls into W API 
calls break Mozilla in a number of places. Fixing all these cases
would take many man-hours and is not feasible at least for 1.0 branch.
Consequently, MS Layer for Unicode is of no use for Mozilla(1.0
branch) at the moment. 

 
> Or do you mean some component aren't Unicode compliant?
  
  Nope.  There might be some such components, but that's nothing
to do with the issue at hand.
Comment 138 Jungshik Shin 2002-06-08 05:39:38 PDT
Sorry for spamming...

> do you mean that Mozilla wasn't programmed as a Unicode application at the 
> very beginning ?  

  See also comment 104.
Comment 139 Roy Yokoyama 2002-06-10 11:02:09 PDT
>Have you treid http://www.hani.co.kr and http://www.lemonde.fr
Not yet.  I haven't got any access violations from my previous test
sites.  However, I'll try your test sites today.  I am also
in the process of having Unicode build column in the tinderbox 
(initially in the SeaMonkey-Ports page).  This way we can slowly
migrate Win32 build to Unicode-Hybrid build and monitor any
build breakages.

(Note Unicode-Hybrid build.  You can see from my patch that I am
designing the code so that the browser will be a true UNICODE app 
in WinNT base OSs where as it will act as ANSI app in Win9x base OSs)
Comment 140 Roy Yokoyama 2002-06-10 11:13:22 PDT
Here is the approach we are basing on.

Design a Single Unicode App that Runs on Both Windows 98 and Windows 2000
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0499/multilangunicode/multilangunicode.htm&nav=/msj/0499/newnav.htm
Comment 141 Jungshik Shin 2002-06-10 17:22:29 PDT
>>Have you treid http://www.hani.co.kr and http://www.lemonde.fr
>Not yet.  I haven't got any access violations from my previous test

  I've tested them on my build ( which was made from mozilla 1.0 branch as of
last Saturday plus your patch) and unfortunately I got the same access
violation as I got with my patch. (I should not forget to mention that
it works on sites like http://cn.yahoo.com). This could well be due to something
peculiar in my environment (Win2k English version with the system locale
set to Korean). Anyway, it'd be nice to see the result of your test
under different environments (WinXP SC, etc)
Comment 142 Roy Yokoyama 2002-06-10 18:02:29 PDT
>>Have you treid http://www.hani.co.kr and http://www.lemonde.fr
Hmmm  No access violations on both sites.  
I am testing them in native Win2K-Ja and native WinXP-SC.
Comment 143 Jungshik Shin 2002-06-10 22:46:43 PDT
>>Have you treid http://www.hani.co.kr and http://www.lemonde.fr
>Hmmm  No access violations on both sites.  
>I am testing them in native Win2K-Ja and native WinXP-SC.

 Thank you for trying it. 

  I made another build this time using Mozilla 1.0 source tar ball
with your patch applied. Your patch got applied without any offset
this time while it got applied with 4~50 lines offset against
Mozilla 1.0 branch I pulled off from the cvs server (has there been
some changes in files like nsWindow.cpp/h since 1.0 release?
Lxr doesn't help me track down these changes, if any, on 1.0 branch). 

 Anyway, the result is the same as before. I tried it this time
under Enlgish locale and English MS Win 2k. Another site I got
access violation is http://www.ohmynews.com 

  Do you have any EN-US Win2k around to try this under? 

BTW, when I tried to build Mozilla with your patch and MOZ_UNICODE set to 1,
'webshell' module(?) didn't get compiled complaining about WindowPopupClass
not resolved. Therefore I had to build Mozilla without MOZ_UNICODE set to 1,
clobber widget module and rebuild widget module only with MOZ_UNICODE set. 

Do you think the way I built mozilla has to do with my problem? I can't think
of any other way until webshell module(?) is tweaked to get compiled with
MOZ_UNICODE
set. 

Perhaps the best way to get this tested as extensively as possible is to
make a binary build available for people under many different environments
to try. I guess that'll be automatically the case when you're done
with adding Unicode-hybrid build column to tinder-box, right? 
Comment 144 Jungshik Shin 2002-06-11 09:49:44 PDT
> BTW, when I tried to build Mozilla with your patch and MOZ_UNICODE set to 1,
> 'webshell' module(?) didn't get compiled complaining about WindowPopupClass
> not resolved. Therefore I had to build Mozilla without MOZ_UNICODE set to 1,
> clobber widget module and rebuild widget module only with MOZ_UNICODE set. 

  This was solved by adding to webshell/tests/viewer/windows/makefile.win 
the following lines (right after DEFINES line)

!ifdef MOZ_UNICODE
DEFINES= $(DEFINES) -DMOZ_UNICODE
!endif 
Comment 145 nhottanscp 2002-06-11 11:10:53 PDT
bug 150131 is for Linux
Comment 146 Roy Yokoyama 2002-06-11 11:38:16 PDT
>Do you have any EN-US Win2k around to try this under? 
No; but I built an optimized build for our iQA to test
under other OS.  I'll ask them to play with it today.
Comment 147 Jungshik Shin 2002-06-11 14:07:56 PDT
> bug 150131 is for Linux.

As I wrote there, this bug was fixed a long time ago for Linux.
See comment 39 to comment 59 and attachment 41935 [details] [diff] [review].
I think there's not much more Mozilla can do under Linux and it's up
to the window manager a user choose to interpret 
_NET_WM_NAME window property (UTF8_STRING) properly.
Comment 148 Marc Mongenet 2002-06-12 16:24:31 PDT
I solved http://bugzilla.mozilla.org/show_bug.cgi?id=150958
and http://bugzilla.mozilla.org/show_bug.cgi?id=104027
on my Linux box for ISO-8859-1 characters.
The only thing I changed was a locale. From:
LANG=POSIX
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_ALL=
To:
LANG=POSIX
LC_CTYPE=fr_CH
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_ALL=

Et voil&#224;!
AFAIK nothing to do with my window manager.
BTW, I use quite old programs, fvwm 2.2.4 and XFree86 3.3.6 (Debian
2.2).

But for non-ISO-8859-1 characters (Korean, Hebrew), I still get
'?' in the window title. But everything else (including tabs title)
is OK, very fine job!
Comment 149 Roy Yokoyama 2002-06-12 18:39:40 PDT
>Do you have any EN-US Win2k around to try this under? 
iQA tried my OPT build on EN-US W2K and worked fine:)
I asked him to try Korean locale. He/I will post the result later.
Comment 150 Ilya Konstantinov 2002-06-13 10:31:21 PDT
Marc, on non NETWM-compliant window managers (like FVWM which you're using), the
title bar would only display languages which your locale can handle.

If you wish to display all languages without switching to a NETWM-compliant
window manager (such as KWin, Metacity...), you might try using a locale which
has a UTF-8 codeset.
Comment 151 Jungshik Shin 2002-06-13 18:37:50 PDT
>>Do you have any EN-US Win2k around to try this under? 
>iQA tried my OPT build on EN-US W2K and worked fine:)
>I asked him to try Korean locale. He/I will post the result later.

  Thank you for trying that. I guess running it under KO locale
won't result in any difference although it'd be nice to see it
confirmed.

  Is there any way for me to try your build on my Win2k EN-US?
I also built an OPT build, but the result is the same. Something
must be wrong on my build environment.(I'm using VC++6.0 with
sp5.) Trying your build and finding that it works fine on my box
would be a strong indication that my build environment is to blame.
Comment 152 Roy Yokoyama 2002-06-14 10:27:22 PDT
I am not certain who I should request for review.
shanjian: can you review my patch?
Comment 153 Jungshik Shin 2002-06-14 16:05:23 PDT
Thank you for sending me your build.

>  Is there any way for me to try your build on my Win2k EN-US?
>I also built an OPT build, but the result is the same. Something
>must be wrong on my build environment.(I'm using VC++6.0 with
>sp5.) Trying your build and finding that it works fine on my box
>would be a strong indication that my build environment is to blame.

  I've just tried your build on my Win2k box. To my great surprise,
it also gave me access violation. It seems like it's not my build
environment but something else on my Win2k box that is to blame. 
Anyway, it appears to be my own problem (with little to do with
the patch). I just don't know what.....
Comment 154 Jungshik Shin 2002-06-14 16:48:29 PDT
At the top of attachment 78132 [details], I have the following lines:  
> ffff025d()
> NPSWF32! 0534bb7a()
> NPSWF32! 0534ae46()
> USER32! 77e139a3()
> USER32! 77e15c95()
> NTDLL! 77fa032f()
> nsView::SetDimensions(const nsRect & {...}, int 1) line 532

I should have noticed immediately that the access violation had occurred
not in Mozilla code but in NPSWF32. NPSWF32.dll is for flash plugin.
(it's beyond me why/how I missed that...) 
I had 5.0 r41 plugin from macromedia. After upgrading it to 
6.0, the problem has gone for good.  Had I realized this
back in early April (when I wrote comment 105), this fix might have
made it in 1.0. Anyway, Roy has come up with a cleaner patch, which
is good.
Comment 155 Roy Yokoyama 2002-06-17 15:45:16 PDT
joe: Can you review my patch? It's #ifdef MOZ_UNICODE so it has no impact on 
     the tree; but once I got the unicode tinderbox column running, I want to 
     be ready.
Comment 156 Roy Yokoyama 2002-06-19 10:17:03 PDT
*** Bug 152839 has been marked as a duplicate of this bug. ***
Comment 157 Kalle Valo 2002-06-19 11:00:59 PDT
*** Bug 152788 has been marked as a duplicate of this bug. ***
Comment 158 Shanjian Li 2002-06-19 14:39:07 PDT
I talked with roy about this bug over the phone. If we can intergrate "Microsoft
Layer for Unicode" before this patch, the code should be much simpler. Roy will
file a bug and we will see what needs to be done. 

Comment 159 Roy Yokoyama 2002-06-19 15:58:34 PDT
just to recap what shanjian and I are suggesting.
- make this patch much simpler by calling pure Unicode APIs only
  (thus no A API calls on Win9x platforms)
- incorporate 'Unicode Layer' library  (bug 118013)

The reasons are as follow
- easy to maintain
- no performance hit on NT base OSs (ie. no if (nsToolkit::mUseWideApi) needed)
  moz may perform better on NT base OSs

Overhead
- "uniocde layer" will be executed in Win9x base OSs.

Action items:
- revise the patch to only include Wide APIs
- add "Unicode Layer" library to the build sytem.
Comment 160 Roy Yokoyama 2002-06-21 11:44:41 PDT
Created attachment 88673 [details] [diff] [review]
use of W-APIs only 

shanjian: can you review?
Comment 161 Shanjian Li 2002-06-24 16:34:40 PDT
Comment on attachment 88673 [details] [diff] [review]
use of W-APIs only 

>+  nsAutoString title;
>+  title.Assign(mTitle);
How about 
    nsAutoString title(mTitle);

>+    nsString dirBuffer;
>+    dirBuffer = initialDir;
Same thing here
      nsString dirBuffer(initialDir);

>+        TranslateMessage(&msg);
>+        DispatchMessageW(&msg);
Is there a W version of TranslateMessage?
Comment 162 Joe Francis 2002-06-25 16:25:04 PDT
un-cc'ing me since i am not qualified to review windows-specific patches.
Comment 163 Roy Yokoyama 2002-06-26 12:25:13 PDT
Created attachment 89307 [details] [diff] [review]
taking shanjian's recommendation

TranslateMessage() doesn't have W version.

shanjian: please review.
Comment 164 Shanjian Li 2002-06-26 13:12:54 PDT
Comment on attachment 89307 [details] [diff] [review]
taking shanjian's recommendation

r=shanjian,
Comment 165 Roy Yokoyama 2002-06-26 13:14:52 PDT
kin: can you super review?
Comment 166 kinmoz 2002-06-28 12:23:57 PDT
Comment on attachment 89307 [details] [diff] [review]
taking shanjian's recommendation

--- Can mDefault ever be empty when this call is made? I'm worried that get()
might return an empty string, and I don't know how the calls that will make use
of this will react to an empty "" string.:


+  wcsncpy(fileBuffer,	mDefault.get(), MAX_PATH);


--- Are we guaranteed that mLastUsedUnicodedirectory will not be empty too at
this point? Once again I'm worried about the initialDir and dirBuffer calls
that do a .get() below this, being unfamiliar with some of the calls that will
use the result of .get(), I'm not sure they will handle a null or empty string.


+  if(initialDir.IsEmpty()) {
+    // Allocate copy of last used dir.
+    initialDir = mLastUsedUnicodeDirectory;
+  }
+


--- Is this guaranteed to never exceed MAX_PATH? Where are we getting MAX_PATH
from?


+      result = ::SHGetPathFromIDListW(list, (LPWSTR)fileBuffer);


--- Fix indention in the 2 places that have this change:


+#ifdef MOZ_UNICODE
+    file->InitWithPath(mUnicodeFile);
+#else
   file->InitWithNativePath(mFile);
+#endif


--- Do we want to rename |_retval| to follow the arg naming conventions used
throughout the source base, and to make them more meaningful?


   NS_IMETHOD Show(PRInt16 *_retval);
+#ifdef MOZ_UNICODE
+  NS_IMETHOD ShowW(PRInt16 *_retval);
+#endif


--- Have you built with MOZ_UNICODE defined and undefined?

--- Is MOZ_UNICODE defined by default by some config file? And do all the win32
platforms everyone builds on (98,2k,XP,NT) support all the 'W' methods?
Comment 167 Simon Montagu :smontagu 2002-06-28 14:16:57 PDT
*** Bug 154881 has been marked as a duplicate of this bug. ***
Comment 168 Roy Yokoyama 2002-06-28 16:15:23 PDT
>--- Can mDefault ever be empty when this call is made? 
>I'm worried that get() might return an empty string, 
>and I don't know how the calls that will make use
>of this will react to an empty "" string.:
Yes, it is possible to be an empty string. I tested with 
a dummy line wcsncpy(fileBuffer, L"", MAX_PATH); and 
it copied an empty string to fileBuffer successfully.

>--- Are we guaranteed that mLastUsedUnicodedirectory 
>will not be empty too at this point? 
No, I guess it is possible to be empty.  However, I am mimicing 
nsFilePicker::ShowW()from the already exiting nsFilePicker::Show().
I test run the ::SHBrowseForFolderW()with empty dirBuffer and worked 
fine after modifing the patch a little for dirBuffer and title to be 
PRUniChar.

>--- Is this guaranteed to never exceed MAX_PATH? 
>Where are we getting MAX_PATH from?
>+      result = ::SHGetPathFromIDListW(list, (LPWSTR)fileBuffer);
MAX_PATH is defined in windef.h and utilized thru out Windows APIs.
( #define MAX_PATH 260 ) SHGetPathFromIDList() is described in 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/Shell/reference/functions/shgetpathfromidlist.asp
which says 
fileBuffer: Address of a buffer to receive the file system path. This buffer
must be at least MAX_PATH characters in size. 
It works. I am simply copying the line from
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsFilePicker.cpp#129
and calling W API instead.   I block tested the code in the debug mode 
and it returns Path correctly.

>--- Fix indention in the 2 places that have this change:
Done!

>--- Do we want to rename |_retval| to follow the arg naming 
>conventions used throughout the source base, and to make them more 
>meaningful?
I chanaged to aReturnVal.

>--- Have you built with MOZ_UNICODE defined and undefined?
Yes, I built it for the second time. 
I'll triple check again before I check into the trunk once 
I got /sr from you.

>--- Is MOZ_UNICODE defined by default by some config file? 
MOZ_UNICODE not defined by default.  I made it to kick in 
when MOZ_UNICODE environment variable is defined just like other
environment variables.  (eg. c:>set MOZ_UNICODE=1)  

>And do all the win32 platforms everyone builds on (98,2k,XP,NT) 
>support all the 'W' methods?
Yes, 'W' methods are defined in the Win32 include files 
in the standard MSVC++ 6.

New Patch to follow........
Comment 169 Roy Yokoyama 2002-06-28 16:27:27 PDT
Created attachment 89631 [details] [diff] [review]
adding kin's recommendations

kin: please super review?
Comment 170 R.K.Aa. 2002-06-28 20:40:35 PDT
*** Bug 154903 has been marked as a duplicate of this bug. ***
Comment 171 kinmoz 2002-07-02 14:03:34 PDT
Comment on attachment 89631 [details] [diff] [review]
adding kin's recommendations

sr=kin@netscape.com

with the removal of the first wcsncpy() call below, like we discussed.

+  PRUnichar fileBuffer[MAX_PATH+1];
+  wcsncpy(fileBuffer, L"", MAX_PATH);
+  wcsncpy(fileBuffer,	mDefault.get(), MAX_PATH);
Comment 172 Roy Yokoyama 2002-07-02 18:05:27 PDT
checked into the trunk
Comment 173 Boris Kirzner 2002-07-03 14:54:34 PDT
Problem is still persists (bild 2002070310 by yokoyama@netscape.com) in the trunk

For example see www.design.ru
Comment 174 Roy Yokoyama 2002-07-03 15:02:55 PDT
>Problem is still persists (bild 2002070310 by yokoyama@netscape.com) in the trunk
Which build are you testing with?  Plain trunk build doesn't fix this bug just
yet.  (thus I didn't close this bug)

If you want to test, you need to do the following after pull the source:
1) set envrionmen variable MOZ_UNICODE (eg. c:>set MOZ_UNICODE=1) 
2) build the mozilla

I've tested your site with my Unicode enabled build and works great
on my Win2k-En.  (no more question marks)

Comment 175 Wesha 2002-07-11 12:24:58 PDT
Soooo, when should we expect to have these question marks eliminated in the
binaries supplied under "Latest Builds" directory?
Comment 176 Jungshik Shin 2002-07-11 14:30:29 PDT
> Soooo, when should we expect to have these question marks eliminated in the
> binaries supplied under "Latest Builds" directory?

 When bug 118013 is resolved and Mozilla becomes a 'Unicode application'
 
In the meantime, you don't have to be
bothered by '?' in the title bar if you're running Mozilla under
Win2k and the only language you're interested in is Russian. You can
just set the system locale of your Win2k to Russian and reboot
and all Russian titles should be rendered all right. 


Comment 177 pantelis.botsas 2002-07-11 23:01:53 PDT
And this is exactly the way I don't want to solve the problem, because then I am
limited to this only selection.
Comment 178 Wesha 2002-07-15 15:47:29 PDT
*** Bug 149908 has been marked as a duplicate of this bug. ***
Comment 179 Wesha 2002-07-16 09:37:44 PDT
Bug 157687 reports same problem with windows titlebar in Mail component, and I
confirm that. Should we change Product from "Browser" to something more broad?
Comment 180 Wesha 2002-07-16 09:38:55 PDT
*** Bug 157687 has been marked as a duplicate of this bug. ***
Comment 181 石庭豐 (Seak, Teng-Fong) 2002-07-16 22:35:33 PDT
Yes, it's everywhere, from browser to mailer as well as composer, but I've just
check the "Product" field and there's no "General" selection.  Anyway, if this
bug is corrected for one, wouldn't it be corrected for all?
Comment 182 Roy Yokoyama 2002-07-17 09:27:05 PDT
>Anyway, if this bug is corrected for one, wouldn't it be corrected for all?
yes, we tested for browser, composer and mail/news.  They worked well.
Comment 183 Frank Tang 2002-07-24 00:31:45 PDT
nsbeta1+ for m1.2final
Comment 184 Frank Tang 2002-07-24 00:33:54 PDT
move this bug from m1.2beta to m1.2alpha
Comment 185 Roy Yokoyama 2002-07-25 10:36:25 PDT
Created attachment 92758 [details] [diff] [review]
Need -DMOZ_UNICODE for \\webshell\test\makefile.*
Comment 186 Roy Yokoyama 2002-07-26 16:42:12 PDT
Created attachment 92976 [details] [diff] [review]
Need to support WindowPopupClass() and WindowClass()

kin: can you review?   Webshell/test app failed to link.
Comment 187 kinmoz 2002-07-29 08:31:40 PDT
Instead of this:


 #ifdef MOZ_UNICODE
     virtual LPCWSTR         WindowClassW();
     virtual LPCWSTR         WindowPopupClassW();
+    virtual LPCTSTR         WindowClass();
+    virtual LPCTSTR         WindowPopupClass();
 #else
     virtual LPCTSTR         WindowClass();
     virtual LPCTSTR         WindowPopupClass();
#endif


do this:


 #ifdef MOZ_UNICODE
     virtual LPCWSTR         WindowClassW();
     virtual LPCWSTR         WindowPopupClassW();
 #endif 
     virtual LPCTSTR         WindowClass();
     virtual LPCTSTR         WindowPopupClass();


Even though you added these new versions of WindowClass and WindowPopupClass()
that call through to your W versions, I'm assuming the other changes you made
previously to call the OS W functions are still needed right?

Comment 188 Roy Yokoyama 2002-07-29 10:10:06 PDT
Created attachment 93168 [details] [diff] [review]
Revised

Uhhhh, I'm so nuthead.	I was thinking of my patch last night.	I should
have been more careful.

>to call the OS W functions are still needed right?
Yes, definitely.  This is to fix the linker error
from //webshell/test.  

shanjian: can you review?
kin: can you super review?
Comment 189 Shanjian Li 2002-07-29 10:47:14 PDT
Comment on attachment 93168 [details] [diff] [review]
Revised

r=shanjian
Comment 190 kinmoz 2002-07-29 10:51:39 PDT
Comment on attachment 93168 [details] [diff] [review]
Revised

sr=kin@netscape.com
Comment 191 Asa Dotzler [:asa] 2002-07-29 12:10:27 PDT
Comment on attachment 93168 [details] [diff] [review]
Revised

a=asa (on behalf of drivers) for checkin to 1.1
Comment 192 ck 2002-08-04 22:04:56 PDT
I want to see Greek in the title bar! Here is another test case for you guys:
http://library.ucy.ac.cy/electronic_services/dbase_interbl3_main_gr.htm

P.S It works in IE6. My OS is Win2000 SP3 and i'm using Mozilla 1.1b
Comment 193 Jo Hermans 2002-08-06 02:57:03 PDT
*** Bug 161248 has been marked as a duplicate of this bug. ***
Comment 194 Sobrinho 2002-08-20 09:50:48 PDT
Created attachment 96031 [details]
Problems with charset Western ISO-8859-1 

Not only in titlebar (see my screenshots)
Comment 195 Sobrinho 2002-08-20 10:05:53 PDT
Comment on attachment 96031 [details]
Problems with charset Western ISO-8859-1 

this attach is a .zip file 

when I click in
Download the attachment instead. 
http://bugzilla.mozilla.org/attachment.cgi?id=96031&action=view

Mozilla 1.1b make download from a file named
"attachment.cgi.exe"

I need rename it for 
"attachment.zip"

but when I donwloaded it with IE 5
it create a file
"attachment.cgi.zip"

I am using Mozilla 1.1b Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b)
Gecko/20020721
build 2002072104
Comment 196 Jungshik Shin 2002-08-20 10:20:13 PDT
> Problems with charset Western ISO-8859-1

> Not only in titlebar (see my screenshots)

  No, your problem has NOTHING to do with this bug.
Please, make sure that your VIEW|Character Encoding
is set to either ISO-8859-1 or ISO-8859-15 when you view the page.


The following is  off-topic :

> Mozilla 1.1b make download from a file named
> "attachment.cgi.exe"

> I need rename it for 
> "attachment.zip"

  Mozilla is 100% compliant to HTTP spec in this
regard. 

> but when I donwloaded it with IE 5
> it create a file
> "attachment.cgi.zip"

  MS IE is NOT compliant to HTTP spec. Its 'arrogant' mime-type 
peeking IGNORES C-T header field sent by http servers.
All right this time, it got it right. However, often times,
it gets it wrong !! 

  When you attached your zip file, you should have
specified MIME type "application/zip".
Apparently, you specified 'application/octet-stream',
instead. Moreover, please use 'jpeg' or 'png' instead
of 'bmp'. 




Comment 197 Wesha 2002-08-20 11:12:53 PDT
Comment on attachment 96031 [details]
Problems with charset Western ISO-8859-1 

Nothing to do with this bug.
Comment 198 Henry James 2002-08-29 05:32:25 PDT
Please can someone give any information why the patch did not make into 1.1?
Comment 199 Roy Yokoyama 2002-09-21 12:37:22 PDT
104934 fixes this bug for Windows NT base systems.
I believe other platforms has the same bug.
This bug is for XP. Marking as fixed
Comment 200 Koike Kazuhiko 2002-09-22 20:47:56 PDT
I reopened bug 109599 for Linux.
Comment 201 Gérard Talbot 2002-09-23 11:13:23 PDT
Titlebar still do not show non-English characters: XP Pro SP1 and build
2002092308 here.

I tried the Greek page given at comment #192 and Greek characters were replaced
by ?'s. Same thing happening with Cyrillic (koi8-r) pages.
Comment 202 Gérard Talbot 2002-09-23 11:15:24 PDT
Titlebar still do not show non-English characters: XP Pro SP1 and build
2002092308 here.

I tried the Greek page given at comment #192 and Greek characters were replaced
by ?'s. Same thing happening with Cyrillic (koi8-r) pages.
Comment 203 Roy Yokoyama 2002-09-23 12:10:21 PDT
drunclear: sorry about this.  The patch was rolled back last night for a scroll-bar
problem caused by Unicode conversion (104934).  I have a patch to fix the
scrollbar  
and you should be on the way to verify this by tomorrow.  Regards.
Comment 204 Gérard Talbot 2002-09-24 10:36:58 PDT
I tested several urls in character coding koi8-r, iso-8859-2, windows-1251,
windows-1253, etc... and they all worked for me with XP Pro SP1, build 2002092408.

Congratulations! You've fixed a 3 year old bug.
Comment 205 石庭豐 (Seak, Teng-Fong) 2002-09-29 10:38:43 PDT
I also have to say: Congratulations !

At last this wicked bug is removed and Mozilla can raise its head one more time
against IE :)

But ...... there's still a problem in Mailer window's title bar. Should I file a
separate bug, or should I send a test case to continue this bug?
Comment 206 Roy Yokoyama 2002-09-29 11:22:58 PDT
>there's still a problem in Mailer window's title bar.
Last time I checked, the mail title bar didn't have problem either.


By the way, this bug will reappear for few days until 104934 get's resolved.
104934 cause few regressions and need to be dealt with.
(170855, 171208, 171228, 170969)  two steps forward, one step back..........
Comment 207 石庭豐 (Seak, Teng-Fong) 2002-09-29 11:54:20 PDT
Be assured, if the email is well formed, there's no problem.  By well-formed, I
mean there's MIME encoding like =?big5?B?Rn...... in Subject field.

The problem comes from web-based emails and other mailers (possibly old
mailers).  There're two cases:
1) The MIME encoding is wrong: the subject is =?iso-8859-1?Q?=B9.... instead of
=?big5?B?.....  (IMO, this happens in Win98)
2) There's no MIME encoding: the subject is something like «Ü¦³·N«ä

In both cases, if I set the View to the right encoding, Subject field will
display the string correctly, but not the title bar.

Do you need test case?
Comment 208 Roy Yokoyama 2002-09-29 15:24:16 PDT
I'd appreciate if you could provide a test case. :)
Comment 209 Timofey Vorobyov 2002-10-01 04:35:21 PDT
confirm it fixed under OS/2, Mozilla 1.1 release
Comment 210 石庭豐 (Seak, Teng-Fong) 2002-10-02 10:26:08 PDT
Created attachment 101419 [details]
Test case
Comment 211 石庭豐 (Seak, Teng-Fong) 2002-10-02 10:28:55 PDT
At the moment I put this test-case, there's indeed a regression, but the bug
isn't due to the regression.  Only try it after the regression has passed.

The test case contains three test-case mails.  For the first two, even if you've
changed the encoding, Mailer title still couldn't display correctly.  The third
one would display correctly without human intervention.
Comment 212 Wesha 2002-10-16 11:03:17 PDT
This bug is NOT fixed. I still observe the problem (as described in bug 137143 
which is a dupe of this one) on build 2002101608/NT4. Please clarify; otherwise 
I'm going to reopen it.
Comment 213 Roy Yokoyama 2002-10-16 11:54:54 PDT
MOZ_UNICODE is turn OFF for now. 
We had some regressions and I was busy on other project.

Please leave this bug as closed.  
104934 will be the bug we need to fix now.
Comment 214 Roy Yokoyama 2002-10-16 13:27:32 PDT
*** Bug 174539 has been marked as a duplicate of this bug. ***
Comment 215 Roy Yokoyama 2002-10-21 09:58:23 PDT
*** Bug 175673 has been marked as a duplicate of this bug. ***
Comment 216 Teruko Kobayashi 2002-10-24 16:50:31 PDT
Changed QA contact to ylong@netscape.com.
Comment 217 Yuying Long 2002-10-24 17:13:29 PDT
This has been verified in Roy's windows unicode build.
Comment 218 Chris Lyon 2002-11-19 22:24:09 PST
*** Bug 168950 has been marked as a duplicate of this bug. ***
Comment 219 Michael Entin 2002-11-27 18:06:25 PST
The last comments on this bug indicate that it is fixed, and the fix will be
visible to users when bug 104934 (Convert Mozilla to Unicode app) is fixed.

Now both bugs are in "resolved fixed" state, but the Mozilla 1.2 (build
20021126) still has this problem. (Repro: visit http://www.russ.ru/ - lots of
???? in window title).

Is it unfixed again?
Comment 220 Simon Montagu :smontagu 2002-11-27 18:26:37 PST
The release notes for 1.2 say that this is not fixed there.

http://www.mozilla.org/releases/mozilla1.2/
Comment 221 石庭豐 (Seak, Teng-Fong) 2002-11-28 05:27:29 PST
I'm using 20021119 built and the fix is there.

However, there's still a little problem in mailer only:

I've got mails whose subjects have wrong MIME encoding which have iso-8859-1
instead of big5.  For example:
=?iso-8859-1?Q?=B9q=A4l=C2=F8=BBx141=B4=C1?=

So I use View > Character Coding to change back to Big5, but Windows title
doesn't reflect this change.

Should I file a new bug for this ?
Comment 222 Chris Lyon 2002-12-01 20:46:47 PST
*** Bug 182949 has been marked as a duplicate of this bug. ***
Comment 223 Simon Montagu :smontagu 2002-12-02 10:11:50 PST
>So I use View > Character Coding to change back to Big5, but Windows title
>doesn't reflect this change.
>
>Should I file a new bug for this ?

Yes, please

Comment 224 Gérard Talbot 2002-12-04 15:09:50 PST
The patch was not embedded into the 1.2.1 release (build 20021130). I checked a
few pages with the following character encoding
koi8-r (Cyrillic), 
win-1251 (Cyrillic), 
iso-8859-2 (Central Europe), 
windows-1253 (Greek)
and the page titles do not show the particular characters.

The page
http://www.mozilla.org/releases/mozilla1.2.1/#international
goes 
"A window title (reflecting the title of a web page) may not show correctly if
the web page (e.g. Japanese) does not match the language of the OS (e.g. English
Windows). (Bug 9449)"

I'd like to understand when Mozilla will display the title of pages (encoded in
non-ideographic character) in nightlies as well as in releases. I'm sure
nightlies had the patch though.
Comment 225 Roy Yokoyama 2002-12-04 15:59:46 PST
>The patch was not embedded into the 1.2.1 release
You are correct.  moz 1.2 is not an unicode build; however,
the nightly trunk build is the Unicode build since 
the beginning of Nov 2002.  Please try latest nightly build 
in your NT base system.
Comment 226 石庭豐 (Seak, Teng-Fong) 2002-12-08 09:35:32 PST
Re comment #221 & #223 :
The problem is filed as bug 184242.
Comment 227 Simon Montagu :smontagu 2002-12-17 14:53:26 PST
*** Bug 185816 has been marked as a duplicate of this bug. ***
Comment 228 Ruslan Ismailov 2003-01-12 05:26:49 PST
*** Bug 188764 has been marked as a duplicate of this bug. ***
Comment 229 Honglin Su 2003-03-16 12:23:55 PST
The problem still exists. 

When I browsed any sites in Chinese, Mozilla 1.3 doesn't render the title bar in
Chinese correctly, however, the content looks fine. 

My laptop is NT 4.0 (English), Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3)
Gecko/20030312.

On the other hand, I tested it in Linux (English, with necessary Chinese fonts),
Mozilla 1.3 can render Chinese title bar correctly. 
Comment 230 Jungshik Shin 2003-03-16 16:29:29 PST
It's for sure fixed for Windows 2k/XP.  As for Win NT 4.0, it's nor
clear how much we're supposed to expect from it in terms of I18N.
If the extent of I18N in NT 4.0 is about the same as that under
Win 9x/ME, what you're observing is normal. The easiest way
to test is to do the same test with MS IE 6.0. Can you see Chinese
title in the title bar with MS IE 6.0 under English NT 4.0? 
Comment 231 Yuying Long 2003-06-10 15:00:10 PDT
This has been fixed for a while, and it works on Win2k/XP, mark as verified fixed.
Comment 232 Wesha 2003-06-10 18:01:30 PDT
But it's still present in NT4.
Comment 233 石庭豐 (Seak, Teng-Fong) 2004-09-09 02:04:01 PDT
I've reported a bug which, IMO, is quite similar to this one.  It's bug 184242.
However, it's not processed.  Did I make mistake in choosing the Component? 
Could someone take a look please?
Comment 234 Robin Monks 2005-01-26 15:16:02 PST
*** Bug 110347 has been marked as a duplicate of this bug. ***
Comment 235 Florian Bender 2014-01-28 05:37:30 PST
The alias "breaks" quicksearch for this query. Since this bug is ooold, I remove the alias.

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