Bug #3385
closed
Failure to handle CDATA nodes correctly
0%
Description
DOM documents created by an XML parser (as distinct from documents created using XSLT) can contain CDATA nodes. There are many paths where we are failing to deal with these.
I came across one, in DomUtils.xmlToStringInner() we have a branch in the switch to handle CDATA nodes, but it wasn't applying escaping. (This caused a failure of one of the copy tests, unfortunately I failed to note which one). I've fixed this on the 2.0 branch.
A search for the constant TEXT_NODE reveals many cases where we handle text nodes without also handling CDATA nodes.
It may be worth doing a soak test of this by modifying the XML parser we use under Nashorn to generate CDATA nodes instead of text nodes.
Updated by Michael Kay over 6 years ago
Also, when we generate JS code to implement a node test for a text() node, it should match CDATA nodes as well as DOM text nodes.
Updated by Michael Kay over 6 years ago
Actually, we have code that normalizes an input tree by replacing all CDATA sections by ordinary text nodes. But the method (spaceStripper in transform.js) is called only if the stylesheet includes a strip-space declaration. It should be called unconditionally.
We may also need to think about documents that can reach us without going through this mechanism, e.g. documents returned from calls to Javascript functions.
Updated by Michael Kay almost 4 years ago
- Description updated (diff)
- Status changed from New to Closed
Closing this because it's three years old and we have no concrete evidence that there is actually a problem.
Please register to edit this issue
Also available in: Atom PDF Tracking page
.