Closed Bug 319959 Opened 19 years ago Closed 19 years ago

CDATA section represented as comment

Categories

(SeaMonkey :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 27403

People

(Reporter: KlausRusch, Unassigned)

Details

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050727
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050727

A CDATA section in an XHTML document when accessed using DOM methods is represented as an HTML comment.

With this XML fragment

	<xml id="demo">
		<attr><![CDATA[123456789]]>
	</xml>

accessing the value of the attr element returns a comment (innerHTML) or the contents of a comment (data).

Reproducible: Always

Steps to Reproduce:
Attached file Sample file
Your example isn't actually a valid XHTML document (missing doctype, unclosed ATTR element, content type text/html), which causes Mozilla to treat it as an HTML document instead.

*** This bug has been marked as a duplicate of 228288 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Comment on attachment 205615 [details]
Sample file

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>Sample page</title>
  <style type="text/css">
    input { position: absolute; left: 200px; };
  </style>
</head>

<body>
	<p>This page contains HTML and an XML data island:</p>
	<pre>
	&lt;xml id="demo"&gt;
		&lt;attr&gt;&lt;![CDATA[123456789]]&gt;&lt;/attr&gt;
	&lt;/xml&gt;  
	</pre>
	<p>
	  The CDATA section is represented as an HTML comment in the DOM tree:
	</p>
	<form id="form">
	  <p>innerHTML: <input type="text" id="innerHTML" name="innnerHTML" size="100"/></p>
	  <p>data: <input type="text" id="data" name="data" size="100"/></p>
	</form>
	<xml id="demo">
		<attr><![CDATA[123456789]]></attr>
	</xml>
	<script type="text/javascript">
	//<![CDATA[
		var attrs = document.getElementsByTagName("attr");
	 var attr = attrs[0];
     document.getElementById("innerHTML").value = attr.innerHTML;
     document.getElementById("data").value = attr.firstChild.data;
	//]]>
	</script>
</body>
</html>
> missing doctype
Agreed. Adding an XHTML doctype does not change the behaviour though.

> unclosed ATTR element
Agreed. This is a typo in the testcase, the problem shows with a closed ATTR element as well though.

> content type text/html
XHTML documents may be served with a doctype of text/html: http://www.w3.org/MarkUp/2004/xhtml-faq#texthtml
The problem is not limited to CDATA sections in XML islands.

Accessing the contents of 
<textarea><![CDATA[123456789]]></textarea>
shows similar behaviour.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: CDATA section represented as commend → CDATA section represented as comment
> XHTML documents may be served with a doctype of text/html:

True, but in this case you can only use the HTML DOM, which does _not_ include CDATA, see http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#ID-E067D597

So, if you want CDATA to be supported by the DOM, you need to send your document as application/xhtml+xml or application/xml, not text/html. See bug 27403.

*** This bug has been marked as a duplicate of 27403 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
See also section C.11 in the XHTML spec (http://www.w3.org/TR/xhtml1/#C_11):

"User agents that access XHTML documents served as Internet media type text/html via the DOM can use the HTML DOM."

"User agents that access XHTML documents served as Internet media types text/xml, application/xml, or application/xhtml+xml can also use the XML DOM."
The XML DOM access does not work with 
  <meta http-equiv="Content-Type" content="application/xml; charset=utf-8" />
either.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Attached file testcase sent as xml
same testcase, sent by server as application/xml
> The XML DOM access does not work with [...] either.

Did you actually _test_ this? It sure does work for me.
This works if the server sets the content type to application/xml, but fails if the content type is set differently by the server (or not provided for file:/// URLs) and overriden in a meta tag:

<meta http-equiv="Content-Type" content="application/xml; charset=utf-8" />
This is getting slightly off-topic now, but you cannot "override" what the server sends with a META tag. See bug 214952, in particular bug 214952 comment 5. Content type for file:// URIs is determined by the file extension, if you rename the document to "foo.xhtml" it will work.

So this is a dup of bug 27403. Don't reopen this bug unless you have a very good reason to do so.

*** This bug has been marked as a duplicate of 214952 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Oops, that was the wrong bug number...

*** This bug has been marked as a duplicate of 27403 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: