Bug 91159 – DOMImplementation::createDocument incorrectly throws a WRONG_DOCUMENT_ERR

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

[Ojan Vafai]

http://www.w3.org/TR/dom/#dom-domimplementation-createdocument

If the doctype is from a different document, it should just be adoptNoded.

[Alexey Proskuryakov]

What do other browsers do? It seems weird to steal doctype from another document's tree like this.

[Ojan Vafai]

Created attachment 152630 [details]
testcase

[Ojan Vafai]

The attached testcase passes in Firefox and fails in WebKit/Opera. I don't see why stealing a doctype is any weirder than any other node. In WebKit, you can adoptNode a doctype and then move it into a Document. In that case, it steals a doctype.

[Alexey Proskuryakov]

This test doesn't check that original document no longer has a doctype after createDocument. However, this is indeed what happens in Firefox in my testing.

> I don't see why stealing a doctype is any weirder than any other node.

I guess it depends on the level of one's familiarity with the API. To me, having DOM modified when document's doctype is used as an argument in createDocument call is surprising - the form of this call doesn't suggest that original document is modified.

What does IE do? Perhaps we have an opportunity to actually improve the Web here, and not just mimic a Gecko quirk.

[Ojan Vafai]

(In reply to comment #4)
> This test doesn't check that original document no longer has a doctype after createDocument. However, this is indeed what happens in Firefox in my testing.

Yeah, it doesn't affect the compatMode of the page though.

> I guess it depends on the level of one's familiarity with the API. To me, having DOM modified when document's doctype is used as an argument in createDocument call is surprising - the form of this call doesn't suggest that original document is modified.

I can see that argument. It doesn't seem much weirder to me than appendChild/insertBefore though.

> What does IE do? 

I'm on vacation now, so don't have easy acces to IE. Haven't tested it.

> Perhaps we have an opportunity to actually improve the Web here, and not just mimic a Gecko quirk.

I don't see throwing an exception here as better. In practice, people almost never use this API. It's not terribly useful. Given that, I think doing the simplest thing is better. IMO, just adoptNode'ing the Node seems simpler to me and it's more consistent with the other DOM modification APIs (appendChild, insertBefore, etc).

[Ojan Vafai]

I would feel differently about this if adding/removing a DocType node affected the compatMode. But, given that it doesn't, I feel like they shouldn't be special.

[Alexey Proskuryakov]

> It doesn't seem much weirder to me than appendChild/insertBefore though.

I think that it is more surprising - when you append/insert a node into a different document, you should not expect it to stay in original tree. But telling a new document what doctype to use does not feel like DOM manipulation on the doctype node.

> I don't see throwing an exception here as better.

I actually had cloning in mind, not even keeping our behavior. I think that testing what IE does would be the right next step.

[Ojan Vafai]

(In reply to comment #7)
> I actually had cloning in mind, not even keeping our behavior.

Oh, I see. That possibility hadn't occurred to me. Seems fine to me.

[Ahmad Saleem]

I am unable to reproduce this bug using attached test case in Safari 15.6 on macOS 12.5 and it shows "PASS" and it does for all other browsers (Chrome Canary 106 and Firefox Nightly 105) as well.

It seems to be fixed along the way, I am going to mark this as "RESOLVED CONFIGURATION CHANGED". Please reopen, if something else is needed. Thanks!