Pages whose titles are in non-Latin scripts (such as Russian) do not display correctly. This is the same behavior as current versions of Communicator, but is not desirable. MSIE displays the URL of the page whenever the script used to show the title of a Web page is incapable of displaying the title of the Web page being displayed; it seems like a good solution to the problem. This is seen in the Jan-14-99 and earlier builds.

Setting all current Open/Normal to M4.

giving all of garret's bugs to don. Don, if you're the wrong person, a thousand apologies.

Resolved as INVALID. Apparently this is a bug against viewer and not apprunner.

Still a problem in apprunner. 1999061409 build, Windows NT 4. Reopening and clearing resolution.

Peter, this isn't really an XPApps issue. Is this for you or the widget folks?

I'm having trouble understanding this bug. It describes the 'title' being garbage for the above URL. Is that the title shown in the titlebar of the window? If so, AppRunner handles this exactly the same as Viewer and Comm 4.6 using the default encoding. I can see that Russian encoding displays wrong for AppRunner, but there is apparently no way to change the encoding in Viewer, so I don't know if this is a Gecko problem or not. Could one of you I18N experts comment on this?

I meant 'Title' to refer to to the title bar of the window, yes. Behavior is currently the same as 4.x (the TITLE specified in the HTML document is written to the title bar, which results in garbage because English Windows NT can't use non-Western languages in title bars), but it should be different (if a TITLE is in a charset the OS can't use, we should substitute the location of the document (its URI) for the TITLE specified in the HTML of the document).

If we have 4.x behavior, then I doubt this is a requirement for Seamonkey, especially since the info you want in the titlebar is already visible in the location bar. Reassigning to danm as p5 for m15, it will almost certainly be latered unless someone knows how to easily implement it.

*** Bug 5967 has been marked as a duplicate of this bug. ***

*** Bug 16798 has been marked as a duplicate of this bug. ***

X11(Unix/Linux) version has the same problem, but X11 has a way to communicate non-Latin-1 strings between clients(ICCCM) by encoding any non-Latin-1 strings in X11 compound Text encoding. Any ICCCM compliant clients(e.g. any modern I18Nized window manager can take care of X11 compound text encoding to display the page title correctly *as long as* it's covered by fonts for the present encoding. Both Motif for NS 4.x/3.x and GTK for Mozilla are ICCCM compliant and NS 4.x/3.x doesn't have this bug (at least in X11) so that Mozilla written using GTK should NOT have this bug, either. Fortunately, Frank Tang came up with the correct diagnosis and patch for X11 Mozilla and I believe it'll solve the problem for X11 Mozilla. As for more generic problem of correctly displaying the page title in the encoding OTHER THAN the encoding supported by the current locale(that is, Japanese page title in Shift_JIS or EUC-JP when window manager is running under Korean locale with EUC-KR encoding, it's for sure not easy to solve if not impossible under the current framework. Only Unicode based locale could handle that kind of multilinguality.

*** Bug 23942 has been marked as a duplicate of this bug. ***

*** Bug 32163 has been marked as a duplicate of this bug. ***

*** Bug 32164 has been marked as a duplicate of this bug. ***

*** Bug 32165 has been marked as a duplicate of this bug. ***

*** Bug 23942 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 9449 ***

Verifying as duplicate (the other bug is more general in scope).