200784 - new XMLSerializer().serializeToString(node) doesn't work for all nodes

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Martin Honnen]

Using JavaScript I am trying to user XMLSerializer to serialize nodes to a
string which are currently not inserted in a document or which are inserted in a
DocumentFragment. I am also trying to serialize a DocumentFragment node.
According to the documentation at
http://unstable.elemental.com/mozilla/build/latest/mozilla/extensions/dox/interfacensIDOMSerializer.html
the method should take any node as an argument:

 wstring nsIDOMSerializer::serializeToString  	(   	in nsIDOMNode   	  root  	)   	
  	

The subtree rooted by the specified element is serialized to a string.

Parameters:
    root 	The root of the subtree to be serialized. This could be any node,
including a Document.


However trying to serialize a document fragment node fails. It would be nice if
you could serialize a document fragment as it is what you get if you extract
content from a range (which for instance the new XPointer processor returns).
If you do not want to support serialization of a document fragment then please
document that.
I also get errors when trying to serialize element nodes or text nodes which are
not inserted into a document or document fragment, that is when parentNode is
null. I don't see why you shouldn't be able to serialize such a node, if that is
intentionally then please document it.
Strangely when I insert an element node into a document fragment then I can
serialize that element node, however a single text node inserted directly as a
child into a document fragment can not be serialized. This seems very
inconsistent and should be fixed, if a document fragement node can not be
serialized I could live with looping through the childNodes and serializing them
but that fails if a text node appears as a child node in the document fragment.

In my view it would be nice and possible to serialize nodes whether they have a
parentNode or not so I would like to see that fixed.
I also don't understand why you can't serialize a document fragment and would
like to see that fixed. Admittedly serialization of a document fragment could
yield a string of not well-formed XML but I think that would be clear to anyone
trying to serialize a document fragment.

I will attach a test case which shows the problems.

Comment 1

[Martin Honnen]

Attachment: test case (test which fail have a read border, tests which work have a green border)

The test case is not "minimal" as it also shows some working cases of node
serialization but I think this is helpful to demonstrate the inconsistencies in
the current implementation where an element node that is a child of a document
fragment can be serialized while serializing a text node that is a child node
of the document fragment causes an error.

Comment 2

[Harshal Pradhan]

I don't see the problem serializing fragments in general. 

There is an issue with orphan text nodes. This is because
nsIDocumentEncoder::Init() fails without a valid document. 
 

Comment 3

[Johnny Stenback (:jst)]

Looks like whoever is calling nsDocumentEncoder::Init() should make sure a
document is always passed in, i.e. if a serializer is serialzing an orphan node
it should grab the document from the caller and pass that in (until we actually
fix GetOwnerDocument() on orphan nodes).

Comment 4

[Alex Vincent [:WeirdAl]]

Attachment: testcase for #document-fragment with two namespaced element child nodes

Something which Martin's testcase didn't cover.  I notice on Linux that all his
testcases with DocumentFragment as the serialized node pass.  This one does not
pass.

Comment 5

[Alex Vincent [:WeirdAl]]

This testcase shows its results after you click on the Dump button.  You should
reasonably see both elements with an xmlns:html attribute.  Instead, only the
first one has it.

The testcase itself serializes a DocumentType node containing two <html:div
xmlns:html="http://www.w3.org/1999/xhtml"> elements.

Comment 6

[Peter Van der Beken [:peterv]]

This was fixed by the fix for bug 27382.