41981 - need to pass XML encoding to nsIDocument

Status: VERIFIED FIXED

(Core :: XML, defect, P3)

Description

[Erik van der Poel]

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.

Comment 1

[Erik van der Poel]

Adding Frank to Cc list. Frank, this is the XML encoding problem (where the info
is not passed to the nsIDocument).

Comment 2

[[e-mail] (away - not reading bugmail)]

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...

Comment 3

[Frank Tang]

the problem is not ine the XMLObserver, but in the nsParser. Currently, we have
no way to tell the nsIDocument about the changes

Comment 4

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 5

[Frank Tang]

I am not sure how important is this. It will only affect XML.

Comment 6

[bobj]

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 7

[Frank Tang]

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

Comment 8

[Frank Tang]

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 9

[Andreas Becker]

nominating for nsbeta1.

Comment 10

[Frank Tang]

shanjian- this is a hard one. please help

Comment 11

[Jaime Rodriguez, Jr.]

Ftang - Do we need this for M0.9.2?

Comment 12

[Frank Tang]

future this one.

Comment 13

[Pawee Lorsuwannarat]

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.

Comment 14

[Shanjian Li]

change nsbranch to nsbranch-

Comment 15

[Teruko Kobayashi]

Nominated this bug to nsbeta1.

Comment 16

[nhottanscp]

nsbeta1+
the user may want to encode XML other than UTF-8

Comment 17

[Shanjian Li]

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. 

Comment 18

[Teruko Kobayashi]

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

[Teruko Kobayashi]

Mac menu issue is the bug 11774.  I cannot verify this on Mac.

Comment 20

[Teruko Kobayashi]

Since bug 11774 is fixed, I verified this in 6-21 Mac OS X branch build.