E4X : ability to preserve CDATA node




JavaScript Engine
10 years ago
5 years ago


(Reporter: Biju, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: testcase)



10 years ago
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:
should display 


10 years ago
Summary: E4X : ability to CDATA node → E4X : ability to preserve CDATA node
Whiteboard: testcase


10 years ago
Blocks: 246441

Comment 1

8 years ago
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 § 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?

Comment 2

8 years ago
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 &lt; 5) alert(true)</script></html>

Raising of course an error if we trying to execute it. Unfortunately we cannot replace all &lt; indiscriminately from the string.

Comment 4

6 years ago
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>;



<foo><bar>1 &lt; 5</bar></foo>

instead of:

<foo><bar><![CDATA[1 < 5]]></bar></foo>

Comment 6

6 years ago
That shouldn't matter in an XML environment. They are equivalent. Doing eval(html..script[0].toString()) works fine. You shouldn't be evaling html..script[0].toXMLString() if that's what you're doing.

Comment 7

6 years ago
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)
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.