Last Comment Bug 389123 - E4X : ability to preserve CDATA node
: E4X : ability to preserve CDATA node
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 All
-- enhancement with 1 vote (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: e4x 380431
  Show dependency treegraph
Reported: 2007-07-21 16:10 PDT by Biju
Modified: 2013-01-02 23:45 PST (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Biju 2007-07-21 16:10:29 PDT
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 
Comment 1 User image Eli Grey (:sephr) 2009-08-21 13:53:05 PDT
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 User image Eli Grey (:sephr) 2009-08-21 14:04:34 PDT
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.
Comment 3 User image Matteo Ferretti [:zer0] [:matteo] 2011-08-03 06:34:16 PDT
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 User image Eli Grey (:sephr) 2011-08-03 13:03:32 PDT
HTML is not XML. Those errors will go away if you serve it as XHTML.
Comment 5 User image Matteo Ferretti [:zer0] [:matteo] 2011-08-03 14:05:42 PDT
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 User image Eli Grey (:sephr) 2011-08-03 14:58:09 PDT
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 User image Eli Grey (:sephr) 2011-08-03 14:59:57 PDT
Well of course text node != cdata node and they are not actually equivalent but assuming proper usage, they are essentially equivalent.
Comment 8 User image Matteo Ferretti [:zer0] [:matteo] 2011-08-03 15:10:46 PDT
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.
Comment 9 User image David Anderson [:dvander] 2011-08-04 15:07:05 PDT
(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.)
Comment 10 User image Matteo Ferretti [:zer0] [:matteo] 2011-08-05 01:09:43 PDT
Thanks David, I had that feeling actually. I joined Mozilla recently so I wasn't sure about it.
Comment 11 User image Matthias Versen [:Matti] 2013-01-02 23:45:49 PST
E4X will be removed again from Spidermonkey (bug 788293)

Note You need to log in before you can comment on or make changes to this bug.