Document doesn't track lost child

[edemaine]

Describe the bug
Since the 0.8.4 update, documents do not seem to realize that they've lost their (only) child when they get reparented.

To Reproduce
https://stackblitz.com/edit/js-xmldom-template-myg9ht?file=index.js

const doc = new DOMParser().parseFromString('<svg/>', 'image/svg+xml');
const oldRoot = doc.firstChild;
const newRoot = doc.createElement('svg');
newRoot.appendChild(oldRoot);
console.log('After first move, document has', doc.childNodes.length, 'children (should be 0)');
doc.appendChild(newRoot);
console.log('After second move, document has', doc.childNodes.length, 'children (should be 1)');

Expected behavior
newRoot.appendChild(oldRoot) should change the oldRoot's parent to be the newRoot, which should mean that the document loses its child. Running the above code in Chrome's console confirms this behavior. Instead I get:

xmldom 0.8.4 instead says that the document still has 1 child after the first move, so the second move fails according to the new one-child-per-document rule. (Error: Hierarchy request error: Only one element can be added and only after doctype)

xmldom 0.8.3 somehow says 1 child after both moves, which is why I didn't see this issue before, but it's still wrong (should be 0 after the first move).

Runtime & Version:
xmldom version: 0.8.4
runtime version: Node v18.7.0
other related software and version: WIndows 11

[karfau]

Thank you for the detailed report.

There was some error in the code sample you added, so I first had some trouble understanding it. But when I checked the stackblitz, I was able to understand it.
That is why I updated the code sample to match the stackblitz code.

There are two issues that are potentially related: #135 #145
I will check that.

As far as I can see at first glance, as soon as move 1 works correctly, move 2 should also work as expected.

I will have to decide which of the two bugs you reported to handle first, but both are top prio now.

[karfau]

Something really strange happened:
after I released 0.9.0-beta.6 I updated the verison in a fork of your stackblitz for this ticket, because I had a suspicion that the fix would also fix this issue.
But in the console that was provided, the error persisted.

Today I finally had time to add your reproduction scenario as a testcase.
But everything worked, nothing was thrown.
It was really confusing.
So I saved and reloaded the stackblitz and also there the errors are gone.

So the good news it I just need to port the fix to the other versions, while the bad thing is, that could already have been done some days ago.

[karfau]

Versions 0.7.9 and 0.8.6 have been released with a fix for this bug

[ewrayjohnson]

In 0.8.6 this is not completely fixed! The (Error: Hierarchy request error: Only one element can be added and only after doctype) is still generated (in my case hundreds of times) greatly affecting performance.
This code from dom.js at line 479, produces the error:

	appendChild:function(newChild){
		return this.insertBefore(newChild,null);
	}

This slightly modified code from the original above produces the error:

    const doc = new DOMParser().parseFromString('<?xml version="1.0" encoding="UTF-8" standalone="yes"?>' +
      '<Properties></Properties>');
    const oldRoot = doc.firstChild;
    const newRoot = doc.createElement('svg');
    newRoot.appendChild(oldRoot);
    console.log('After first move, document has', doc.childNodes.length, 'children (should be 0)');
    doc.appendChild(newRoot);
    console.log('After second move, document has', doc.childNodes.length, 'children (should be 1)');

[karfau]

@ewrayjohnson thank you for reporting, I will have a closer look today, to decide if I need to reopen this issue or we should have a separate one.
Thank you for providing the changed input.

[karfau]

@ewrayjohnson the firstChild that you are moving into the svg tag is it processing instruction (<?xml version="1.0" encoding="UTF-8" standalone="yes"?>), so after that there is still the Properties element in the DOM, so no new elements can be added.
This is the expected behavior.

if you want to remove the first element you should be able to use documentElement instead of firstChild:
https://stackblitz.com/edit/js-xmldom-template-k94zdq?devToolsHeight=33&file=index.js

If you want to provide a different example, which is closer to what you are trying do do, please report a new issue.