Closed
Bug 41981
Opened 24 years ago
Closed 23 years ago
need to pass XML encoding to nsIDocument
Categories
(Core :: XML, defect, P3)
Core
XML
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: erik, Assigned: shanjian)
References
Details
(Keywords: intl)
Currently, when the parser encounters an <?xml encoding="..."?> attribute, it sets the encoding in the parser itself, but fails to pass this info to the nsIDocument object. The parser does not have a pointer to the nsIDocument (I think), so we would need to have the nsIDocument register itself as an observer of the parser's charset (encoding). When the parser's charset changes, it calls all of the observers to notify them of the new value. The presentation context currently observes the document's charset in the same way, so you could look at this to get some ideas.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Comment 1•24 years ago
|
||
Adding Frank to Cc list. Frank, this is the XML encoding problem (where the info is not passed to the nsIDocument).
Comment 2•24 years ago
|
||
Frank, as already discussed with you I was trying to look into the metaCharsetObserver and XMLEncodingObserver. I saw some funny stuff in the way some topics were registered, but didn't get much beyond that...
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
Comment 3•24 years ago
|
||
the problem is not ine the XMLObserver, but in the nsParser. Currently, we have no way to tell the nsIDocument about the changes
Status: NEW → ASSIGNED
Comment 5•24 years ago
|
||
I am not sure how important is this. It will only affect XML.
This is a correctness problem. All internal Mozilla XML files are encoded in UTF-8, but it is legal for XML to be encoded in other encodings and we should support the XML encoding tag! Folks using simple text editors to create XML, may end up creating XML in "native" encodings.
Comment 8•23 years ago
|
||
Even without passing xml encoding to the nsIDocument, we will still convert correctly, the problem is 1. the lang group pass down will be wrong 2. if we try to find out the charest, it will be wrong 3. if one day we will post a form, the data will always post as utf-8.
Comment 10•23 years ago
|
||
shanjian- this is a hard one. please help
Assignee: ftang → shanjian
Status: ASSIGNED → NEW
Comment 11•23 years ago
|
||
Ftang - Do we need this for M0.9.2?
Comment 13•23 years ago
|
||
xhtml 1.0 specification: an XML like the one above is not required in all XML documents. **XHMTL document authors are strongly encouraged to use XML declaration in all their documents. Such a declaration is required when character encoding of the document is other than the default UTF-8 or UTF-16.** I hope this will be fixed before the release of Mozilla 1.0.
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 14•23 years ago
|
||
change nsbranch to nsbranch-
Comment 16•23 years ago
|
||
nsbeta1+ the user may want to encode XML other than UTF-8
Assignee | ||
Comment 17•23 years ago
|
||
This problem does not exist any more. We detect xml encoding in "DetectByteOrderMark" in nsParser.cpp. I verified this with a simple shift-jis encoded xml testcase. Charset is displayed correctly in encoding menu, and font changes as Japanese font preference changes.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 18•23 years ago
|
||
I verified this with 01-29 Trunk Win32 and Linux. However, the mac build does not give the users the right encoding fallback from the menu. I think this is general the Mac menu problem. I will find the bug report for this mac menu issue.
Comment 19•23 years ago
|
||
Mac menu issue is the bug 11774. I cannot verify this on Mac.
Comment 20•22 years ago
|
||
Since bug 11774 is fixed, I verified this in 6-21 Mac OS X branch build.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•