Bug 35130 – importNode cannot import a CDATA element into an HTML document

• Component: DOM
• Status: RESOLVED CONFIGURATION CHANGED

[nemo]

BTW, this used to work at some point in the past, I just noticed webkit based browsers failing recently, so is probably a regression.

Also works perfectly in Firefox.

The reason for this is for a print popup that shows a view of the page w/ the print stylesheet applied (also erases all display: none nodes for easy user copying of the visible data w/o display: none junk).

In Firefox (and older Webkit), I simply do a window.open('',params); then document.write/document.close a blank document, then, in my new blank document I do:
        var x  = printPopup.document.importNode(document.body,true);
        var n  = printPopup.document.body;
        var np = n.parentNode;
        np.removeChild(n);  /* using replaceChild is sometimes buggy in some browsers when replacing entire doc */
        np.appendChild(x);

On my new clone of the parent page I then busy myself cleaning up the dom and changing this and that.

In release and nightly  versions of Safari and Chromium I now get: Error: NOT_SUPPORTED_ERR: DOM Exception 9
I thought I'd work around that by importing document.body and document.head separately (the only two parts I really care about) but no, I get the same error on import of document.head.  

I'm going to try shunting Safari and Chromium into my IE workaround, but it is not as good a copy and will require adding non-IE variants of things.

[nemo]

http://m8y.org/tmp/scroll_bug.xhtml

Adding link to a demo page that I had made for a Firefox bug (that they since fixed).

Click on the button on the page.  You should see a copy of the parent page inside the child (try it in Firefox).
In chrome and webkit, you will just see a blank page.

Dec 04, 2008 I noticed that Chrome was failing at a document.write (it succeeds at that now) so I filed:
http://code.google.com/p/chromium/issues/detail?id=5105

A month and a half later clearly this new issue cropped up, and [e-mail] closed out #5105 as invalid.

[nemo]

BTW, Opera 10 still works just fine.

Also, I wrapped the importNode in a try/catch and used that instead of existence of importNode to determine shunting into the IE hacks section.

Means as good a clone (innerHTML!=importNode) but usually works "good enough".

Also means once you guys fix this Webkit will use the cleaner behaviour again. :)

[nemo]

... er. means *NOT* as good a clone.

[nemo]

Um. Sorry for bug spam (I'll stop, I promise), but in initial comment I noticed I said document.body.

That should have read document.documentElement - as in the linked testcase.

document.body *does* work in Webkit, it just is pretty much completely useless for me without document.head. (and just using document.documentElement is much more convenient and avoids some manual copies.

[nemo]

Followup.

Looks like Webkit is choking on the CDATA. Stripped the XHTML niceities here:
http://m8y.org/tmp/scroll_bug2.html

Works in Webkit again.  Useless for the site I'm actually using it on though.

[Alexey Proskuryakov]

I'm a bit confused by the plethora of comments, and the latest linked test case doesn't seem to have pass/fail criteria spelled out.

It's no doubt possible to re-create the problem form the above description, but it would be even better if you could attach a final test case with clear steps to reproduce in Bugzilla.

[nemo]

Regarding comment #6.
The last attached testcase was simply showing a workaround.
Focus on the testcase linked in the bug which has pass/fail clearly spelled out.

But, to make it even clearer I've stripped down the testcase further, and updated the URL.
Just use:
http://m8y.org/tmp/webkit_import_bug.xhtml

BTW, if you found this confusing, you must have a rough time with those bugs like "MSN displays funny" ;)

[nemo]

Created attachment 49083 [details]
Demonstration of bug

As requested, attaching the file as well

[Alexey Proskuryakov]

This happens because we refuse to create CDATA sections in HTML documents:

PassRefPtr<CDATASection> Document::createCDATASection(const String& data, ExceptionCode& ec)
{
    if (isHTMLDocument()) {
        ec = NOT_SUPPORTED_ERR;
        return 0;
    }
    return CDATASection::create(this, data);
}

Not sure if this is correct or not - CDATA certainly makes no sense in HTML. FWIW, a direct call to document.createCDATASection() also raises an exception in Firefox in HTML documents - maybe it just skips over those when cloning, or converts them to text nodes?

[nemo]

Testcase was XHTML, not HTML.

And both Opera and Firefox function correctly.

[nemo]

Hm. Ok. You're right. The document *created* by the window.open is treated as HTML, regardless of what the document.write actually wrote...
and printPopup.document.createCDATASection does indeed fail in Firefox.
I suppose Firefox and Opera do deal with it in that way.

[nemo]

Hum. There really is no obvious way to import one XHTML document into a popup without having a source XHTML document for the popup to start with.  Hmmm.  In my case, that might be doable, although it'd still be nice if those nodes were just dropped by Webkit.

Well, nice to know there is actually a sane reason for it.  Also presumably webkit would have blown up on the page with SVG too.  But then, that one didn't have a popup on it.

[WGH]

Yet it works in all other browsers (Firefox, IE10 even).

Why can't we just convert CDATA to text nodes? CDATA is just syntactic sugar that allows XML writers escape less.

[WGH]

Has been fixed in Chromium recently. 
https://code.google.com/p/chromium/issues/detail?id=340059

[Ahmad Saleem]

I took test cases from related Chrome bug mentioned in Comment 14 and changed them into JS Fiddle:

Test Case 1 - https://jsfiddle.net/0hpxkf4a/show

Test Case 2 - https://jsfiddle.net/ba6cusfx/show

For both, all browsers (Chrome Canary 106, Firefox Nightly 105 and Safari 15.6 on macOS 12.5) are in consensus and show following results:

*** Test Case 1 ***

No CDATA

parsed: [object XMLDocument]
imported: [object Element]

With CDATA

parsed: [object XMLDocument]
imported: [object Element]

*** Test Case 2 ***

PASS

_______

I am marking this as "RESOLVED CONFIGURATION CHANGED". Please reopen, if this is not resolved. Thanks!