Bug 246899

Summary: document.adoptNode is a no-op when called on a template element's document fragment
Product: WebKit Reporter: huocp
Component: DOMAssignee: Ryosuke Niwa <rniwa>
Status: RESOLVED FIXED    
Severity: Normal CC: annevk, bigopon.777, cdumez, karlcow, m.goleb+bugzilla, rniwa, webkit-bug-importer
Priority: P2 Keywords: BrowserCompat, InRadar
Version: Safari 16   
Hardware: All   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=204980
Attachments:
Description Flags
testcase for adoptnode none

Description huocp 2022-10-21 23:36:46 PDT 
Safari 16+ (including 16.1 beta and Safari Technology Preview) seems didn't assign ownerDocument correctly in DOM api document.adoptNode.
Reproducible on both mac and iPhone.

In Safari 16+ browser console, reproduce it with following code:
> const div = document.createElement('div')
div.innerHTML = '<template><p></p></template>';

const fragment = div.firstChild.content;
< "<template><p></p></template>"
> fragment.ownerDocument.documentElement
< null
> document.adoptNode(fragment);
< Document Fragment
> fragment.ownerDocument.documentElement
< null

In comparison, in other browser (Chrome, Firefox or older Safari), the ownerDocument is assigned after adoptNode.

> const div = document.createElement('div')
div.innerHTML = '<template><p></p></template>';

const fragment = div.firstChild.content;
< '<template><p></p></template>'
> fragment.ownerDocument.documentElement
< null
> document.adoptNode(fragment);
< #document-fragment
> fragment.ownerDocument.documentElement
< <html ...>
Comment 1 huocp 2022-10-22 15:47:40 PDT 
Found https://github.com/WebKit/WebKit/pull/2034

It's probably a changed behaviour following changed spec. Pls close it if this is not a bug.
Comment 2 huocp 2022-10-23 02:32:54 PDT 
OK, I found an issue without involving adoptNode api.

create a test.html file with following content

<!doctype html>
<html>
<body>
<template id="a">
<p>1</p>
</template>
</body>
</html>

Open it in Safari 16+.
Try in console:

> var d = document.querySelector('#a')
< undefined
> d;
< <template id="a">…</template>
> d.content
< Template Content
> d.content.ownerDocument
< #document
> d.content.ownerDocument.documentElement
< null

Should not every node in this static html file have ownerDocument pointing to the document itself??

The null ownerDocument.documentElement seems not right for the content of HTMLTemplateElement.
Comment 3 huocp 2022-10-23 02:40:24 PDT 
(In reply to huocp from comment #2)
> OK, I found an issue without involving adoptNode api.
> 
> create a test.html file with following content
> 
> <!doctype html>
> <html>
> <body>
> <template id="a">
> <p>1</p>
> </template>
> </body>
> </html>
> 
> Open it in Safari 16+.
> Try in console:
> 
> > var d = document.querySelector('#a')
> < undefined
> > d;
> < <template id="a">…</template>
> > d.content
> < Template Content
> > d.content.ownerDocument
> < #document
> > d.content.ownerDocument.documentElement
> < null
> 
> Should not every node in this static html file have ownerDocument pointing
> to the document itself??
> 
> The null ownerDocument.documentElement seems not right for the content of
> HTMLTemplateElement.

Please ignore my previous comment2, just found out all other browsers do the same.
Comment 4 Karl Dubost 2022-10-23 23:14:59 PDT 
Created attachment 463188 [details]
testcase for adoptnode

Firefox and Chrome return an HTMLHtmlElement object
Safari returns `null`
Comment 6 Ryosuke Niwa 2022-10-25 13:52:38 PDT 
This is intentional behavior change per https://github.com/whatwg/dom/pull/819
Comment 7 bigopon.777 2023-02-23 14:05:32 PST 
It has been noted that the approach in the web spec isn't "web compatible", and it shouldn't be implemented. A quick link https://github.com/whatwg/dom/pull/819#discussion_r1007199723

Can we please have this commit reverted?
Comment 8 Karl Dubost 2023-03-02 19:52:58 PST 
The discussion for the initial breakage is
https://github.com/aurelia/framework/issues/1003

As of today
https://bug-246899-attachments.webkit.org/attachment.cgi?id=463188

# STP 164 
fragment.ownerDocument.documentElement: null
Then document.adoptNode(fragment);
fragment.ownerDocument.documentElement null

# Firefox Nightly 112.0a1 (2023-03-02)
fragment.ownerDocument.documentElement: null
Then document.adoptNode(fragment);
fragment.ownerDocument.documentElement [object HTMLHtmlElement]

# Chrome Canary 113.0.5627.0
fragment.ownerDocument.documentElement: null
Then document.adoptNode(fragment);
fragment.ownerDocument.documentElement [object HTMLHtmlElement]

We probably need to reverse this change and see if there is a path forward in the specification as being discussed in https://github.com/whatwg/dom/pull/819


I'm reopening the bug.
Comment 9 Ryosuke Niwa 2023-03-09 22:41:13 PST 
Pull request: https://github.com/WebKit/WebKit/pull/11347
Comment 10 EWS 2023-03-10 00:30:13 PST 
Committed 261491@main (dd0a5a2fd2e2): <https://commits.webkit.org/261491@main>

Reviewed commits have been landed. Closing PR #11347 and removing active labels.
Comment 11 Radar WebKit Bug Importer 2023-03-10 00:31:18 PST 
<rdar://problem/106542160>