49442 - CDATASection nodes are returned as type 8 not 4 from nodeType()

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect, P3)

Description

[Anthony Truhlar]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; en-US; m17) Gecko/20000807
BuildID:    2000080712

The JavaScript function nodeType() returns the nodeType as 8 which
is comment, instead of 4 which is CDATASection. Thus when serializing
a document through the JavaScript DOM interface it is necessary to use
a regular expression to check for CDATA[, etc. to ensure that you
are not writing out a comment.

Reproducible: Always
Steps to Reproduce:
1.Load the URL above.
2.Click OK on the dialogs - these display (albeit crudely) the current
node name, type and value - this is done recursively.

Actual Results:  Watch for #comment, which is returned for both my opening
comment at the top of the HTML source and also for the CDATASection entry which
should be returned as #cdata-section.

The URL is quick example I knocked up this morning, but this happens
in a more complicated XML document serializer that I have been working
on. It is currently necessary to use a regexp to check for CDATA etc.
so one can be sure whether or not the node is actually a comment or
not.

Expected Results:  Stated above.

This bug ocurred in M17 build 2000080712 on Linux (i686, Debian
(potato)) and is not unique to that release. I tested this on the
Win32 build of M17 on my NT 4.0 workstation box at home and the same
thing happens (same build ID).

Comment 1

[Johnny Stenback (:jst)]

The reason for this is that the file is served by the server as an text/html
file even if it's an XHTML file, if it's served by the server as an text/xml
file then it works.

The reason it doesn't work in HTML is that the HTML parser thinks that anything
that starts with '<!' is a comment. This is wrong by the SGML spec but I'll let
the parser people decide on what to do here. Reassigning to Harish.

Comment 2

[harishd]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration -----

Comment 3

[Jan Carpenter]

Mass update of qa contact

Comment 4

[Prashant Desale]

QA contact Update

Comment 5

[Prashant Desale]

Updating QA contact to Shivakiran Tummala.

Comment 6

[Christopher Hoess (gone)]

Hmmm.  This is interesting.  Looking at nsHTMLTokenizer.cpp, the correct code 
is in there to recognize CDATA sections (line 954, "ConsumeSpecialMarkup") 
(although anything with the markup "<[" to start it will be recognized as CDATA-
that's not quite correct, is it?), and it looks like these are understood by 
CNavDTD.cpp as well.  I wonder if it has anything to do with being in an IE-
style XML data island, which Mozilla doesn't really understand...Reporter, have 
you tried this with XHTML documents (text/html or text/xml)?

Comment 7

[Christopher Hoess (gone)]

Oh dear. The problem here goes rather deeper than I initially thought. The
tokenizer knows about CDATA, and hands the sections off correctly marked, but
the content sink seems to treat them as identical with comments when they are
created in the document, possibly because we don't implement their insertion via
DOM. See also bug 96341. IOW, this bug is occurring because the CDATA section
*is* a comment to our DOM.

Since the difference between comments and CDATA is important to scripts in
XHTML, maybe the priority on this should be raised a bit. harishd, does this
still fall within your domain, or would this be jst?

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Since the difference between comments and CDATA is important to scripts in
> XHTML

Only in XHTML served as XML, actually.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

test cases.
(from bugzilla-jp http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=3659 )

case1: text/html(Standards mode)
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=2063&action=view
case2: text/html(Quirks mode)
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=2064&action=view
case3: application/xhtml+xml
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=2065&action=view

the case1 and 2 have invalid markup sections(sections are not closed)
after paragraph that containts is " following paragraph is wrong CDATA section.".
With 2004030309-trunk/WinXP, this wrong section is *not* exists in source viewer.
this problem is major problem in the Japanese famous company website.
http://www.kao.co.jp/products/asience/

# the case3 doesn't have invalid markup section.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Just wanted to point out that this is a problem only in tag-soup documents, not
in XML/XHTML/whatever, and that whoever's using CDATA in tag-soup is just asking
for trouble.

Comment 9 is not related to this bug in any way whatsoever.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I file a new bug for comment 9.
See bug 236517.

Comment 12

[Boris Zbarsky [:bzbarsky]]

So the code that converts CDATA sections to comments is in CNavDTD.cpp.  Note
that we _should_ be rendering CDATA as comments in HTML (unlike XML).  So I
think what we're doing here is pretty reasonable....  Much more reasonable than
special-casing the rendering of CDATA sections in HTML.

Comment 13

[Hixie (not reading bugmail)]

Well, we _could_ just support CDATA sections in HTML... it's valid, after all.
But WONTFIX sounds good to me too!

Comment 14

[Boris Zbarsky [:bzbarsky]]

> Well, we _could_ just support CDATA sections in HTML... it's valid, after all.

No, we could not.  Sites expect them not to render, from what I've seen....

Comment 15

[Hixie (not reading bugmail)]

in that case the path is clear