Bug 17765 – Empty CDATA section is not added to DOM when parsing

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: DOM

[benoit]

it's not possible to retrieve an empty cdata section (<![CDATA[]]>) with the firstChild property : null is return.

Ex: <testWebkit><![CDATA[]]></testWebkit>

with node = <testWebkit>
var child = node.firstChild;

on safari child is null
on ie 6 and ff 2 child is a node type 4 (CDATA_SECTION_NODE) with an empty content

tested on safari 3.0.4 and nightly build 30790

[benoit]

Created attachment 19661 [details]
html test with domparser

html test. Use domparser but the pb is the same with xmlhhtprequest.
This test does not work on ie (replace domparser with ActiveXObject)

[Jeff Walden (remove +bwo to email)]

Not just firstChild, seems to be anywhere in a particular container.

[Alexey Proskuryakov]

Confirmed with r30984.

[Vincent Ricard]

With r34104 i got the right resut: "first.child type = 4"

[Alexey Proskuryakov]

I'm still getting "first child is null" on the attached test case (also with 34104, local release build).

[benoit]

I'm still getting "first child is null"  with 35844 

[benoit]

probably depends on 
http://bugzilla.gnome.org/show_bug.cgi?id=514181

[Alexey Proskuryakov]

Seems to be working in Safari 5.1 on Lion. We'll need to land this test to avoid regressions.

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.

[Ahmad Saleem]

I am unable to reproduce this bug using attached test case in Safari 15.6 on macOS 12.5 and it shows "first child type = 4" and matches with all other browsers (Chrome Canary 106 and Firefox Nightly 105). I think this can be marked as "RESOLVED CONFIGURATION CHANGED". Thanks!

From Comment 8 - it seems we need to land this test case to avoid future regressions but I am not sure whether we have WPT coverage or not. Please do accordingly. Thanks!

[Ryosuke Niwa]

Yup, config changed.