Closed
Bug 66584
Opened 24 years ago
Closed 24 years ago
win/gtk embed ignores metacharset
Categories
(Core :: Internationalization, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: bstell, Assigned: tetsuroy)
References
()
Details
(Keywords: intl)
Attachments
(3 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Metacharset is ignored by winembed and gtkembed.
If the URL presents a http header charset it display correctly.
http://warp.netscape.com/employees/erik/tests/fonts/
ftang pointed out that the metacharset observer needs to be registered at
application initialization
http://lxr.mozilla.org/seamonkey/source/intl/chardet/public/nsIMetaCharsetServic
e.h#32
and started. See nsAppShellService.cpp for an example:
http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsAppShellService.cpp#
150
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
Reporter | ||
Comment 3•24 years ago
|
||
libchardet.so is also required for metacharset to be recognized
Reporter | ||
Comment 4•24 years ago
|
||
Roy, would you try this patch on windows?
Assignee | ||
Comment 5•24 years ago
|
||
bstell: Should we call nsIMetaCharSetService::End() to clean up the service?
Also what is the equivalent file for libchardet.so in Win32? Instanciation of
nsIMetaCharSetService fails in Windows. Thus Start() method never get called.
Comment 6•24 years ago
|
||
>bstell: Should we call nsIMetaCharSetService::End() to clean up the service?
we should
Assignee | ||
Comment 7•24 years ago
|
||
You need to copy chardet.dll. It works now. :)
Reporter | ||
Comment 8•24 years ago
|
||
Assignee | ||
Comment 9•24 years ago
|
||
The new patch works fine in Win32.
Comment 10•24 years ago
|
||
the meta charset service can arguably be started somewhere else than app
startup, until we get there though, it should leverage a generic app startup
observer (66020)
No longer depends on: 60117
Comment 11•24 years ago
|
||
Changed QA Contact to andreasb@netscape.com for now.
QA Contact: teruko → andreasb
Comment 12•24 years ago
|
||
When will this fix be checked in the mozilla tree?
Reporter | ||
Comment 13•24 years ago
|
||
This patch mimics what mozilla currently uses to enable metacharset.
Valeski vetoed this (he didn't like the design and didnt' want it replicated) so
the patch http://bugzilla.mozilla.org/showattachment.cgi?attach_id=23601 will
not be checked in.
Yokoyama has been working on a better solution; see bug 66020.
Once that is solved I will determine what work if any needs to be done here.
Assignee | ||
Comment 14•24 years ago
|
||
bstell: Do you want to assign this bug to me? My patch for 66020 will
fix this bug.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 16•24 years ago
|
||
The patch is checked in via 66020.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → mozilla0.9
Assignee | ||
Comment 18•24 years ago
|
||
You have to do the following:
===========Comment from 66030===========
Now the meta charset detector is in place,
it is up to the embedder to include which language he/she
likes to support.
If he/she would like to support:
-Japanese, copy components/ucvja.dll-korean,
copy components/ucvko.dlland so on.
Comment 19•24 years ago
|
||
I verified this on 4-18 Embed Win build on Winnt 4.0J and Win98J.
You need to log in
before you can comment on or make changes to this bug.
Description
•