Closed
Bug 2426
Opened 26 years ago
Closed 25 years ago
Title shows garbage text for non-Western pages
Categories
(Core :: XUL, defect, P5)
Tracking
()
M15
People
(Reporter: cpratt, Assigned: danm.moz)
References
()
Details
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.
Comment 2•26 years ago
|
||
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.
Status: RESOLVED → REOPENED
Component: Windows FE → XP Toolkit/Widgets
Priority: P2 → P3
Product: MozillaClassic → Browser
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?
Comment 6•26 years ago
|
||
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).
Updated•26 years ago
|
Assignee: trudelle → danm
Priority: P3 → P5
Target Milestone: M15
Comment 8•26 years ago
|
||
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. ***
Assignee | ||
Comment 10•25 years ago
|
||
*** Bug 16798 has been marked as a duplicate of this bug. ***
Comment 11•25 years ago
|
||
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.
Comment 12•25 years ago
|
||
*** Bug 23942 has been marked as a duplicate of this bug. ***
Comment 13•25 years ago
|
||
*** Bug 32163 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
*** Bug 32164 has been marked as a duplicate of this bug. ***
Comment 15•25 years ago
|
||
*** Bug 32165 has been marked as a duplicate of this bug. ***
Comment 16•25 years ago
|
||
*** Bug 23942 has been marked as a duplicate of this bug. ***
Comment 17•25 years ago
|
||
*** This bug has been marked as a duplicate of 9449 ***
Status: NEW → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 18•25 years ago
|
||
Verifying as duplicate (the other bug is more general in scope).
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•