Closed Bug 389123 Opened 17 years ago Closed 12 years ago

E4X : ability to preserve CDATA node

Categories

(Core :: JavaScript Engine, enhancement)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
All
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: BijuMailList, Unassigned)

References

Details

(Whiteboard: testcase) 

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>"
Summary: E4X : ability to CDATA node → E4X : ability to preserve CDATA node
Whiteboard: testcase
Blocks: e4x
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 §13.4.4.39. 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 &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.
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 &lt; 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[0].toString()) works fine. You shouldn't be evaling html..script[0].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)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.