Just like * XML.ignoreComments * XML.ignoreProcessingInstructions * XML.ignoreWhitespace we need a boolean e4x setting something like * XML.preserveCDATA when it is "true" toXMLString (also when uneval) should show the original <![CDATA]> node. test case: alert((<a><![CDATA[<!--]]></a>).toXMLString()); should display "<a><![CDATA[<!--]]></a>"
Is there any possible workaround? I want to be able to send some E4X XML using an XHR but the sent string is invalid XML due to the <![CDATA[..]]> wrapping of CDATA nodes being hidden. Also, I can't find any mention of removing the <![CDATA[..]]> part of CDATA nodes in ECMA-357 2nd edition §10.2 or §188.8.131.52. Am I wrong to say that we should not remove any part of CDATA nodes to begin with? You can't do much with an invalid string representation of XML. Is there any practical use-case for having "<a><!--</a>" as a string representation of the test case?
Nvm the part about the string being invalid XML in my previous comment, that part was a problem with my function. I still agree there should be XML.preserveCDATA.
Anyone is working on this bug? It actually prevent e4x to work correctly with scripts. So, for instance, if we have: var html = <html><script><![CDATA[ if (1 < 5) alert(true) ]]></script></html>; what we obtain using toString() and toXMLString() methods is actually: <html><script>if (1 < 5) alert(true)</script></html> Raising of course an error if we trying to execute it. Unfortunately we cannot replace all < indiscriminately from the string.
HTML is not XML. Those errors will go away if you serve it as XHTML.
Thanks for the hint, but I'm in a pure JS environment, so it has nothing to do with content type. I used the example of html, but in every node the CDATA section is replaced with the encoded content. So: var foo = <foo><bar><![CDATA[ 1 < 5 ]]></bar></foo>; dump(foo); give: <foo><bar>1 < 5</bar></foo> instead of: <foo><bar><![CDATA[1 < 5]]></bar></foo>
That shouldn't matter in an XML environment. They are equivalent. Doing eval(html..script.toString()) works fine. You shouldn't be evaling html..script.toXMLString() if that's what you're doing.
Well of course text node != cdata node and they are not actually equivalent but assuming proper usage, they are essentially equivalent.
I don't agree. As you said, text node and CDATA node are quite different. The point is: we shouldn't get rid of the CDATA node. The current implementation basically replaced the CDATA node with the encoded text node, and it's impossible get the original, unencoded, value for the whole xml document. The e4x implementation of ActionScript and Rhino works as expected. I didn't find any workaround for that, and I can assume it's a bug of this implementation.
(In reply to comment #3) > Anyone is working on this bug? No one at Mozilla, no. We are not actively maintaining E4X except for security bugs and recommend that it not be used. (Also see bug 670059 where we are measuring whether we can disable it for some configurations.)
Thanks David, I had that feeling actually. I joined Mozilla recently so I wasn't sure about it.
E4X will be removed again from Spidermonkey (bug 788293)