WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
246899
document.adoptNode is a no-op when called on a template element's document fragment
https://bugs.webkit.org/show_bug.cgi?id=246899
Summary
document.adoptNode is a no-op when called on a template element's document fr...
huocp
Reported
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 ...>
Attachments
testcase for adoptnode
(1.10 KB, text/html)
2022-10-23 23:14 PDT
,
Karl Dubost
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
huocp
Comment 1
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.
huocp
Comment 2
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.
huocp
Comment 3
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.
Karl Dubost
Comment 4
2022-10-23 23:14:59 PDT
Created
attachment 463188
[details]
testcase for adoptnode Firefox and Chrome return an HTMLHtmlElement object Safari returns `null`
Karl Dubost
Comment 5
2022-10-23 23:46:27 PDT
There was recent changes to this code. 5 days ago.
https://github.com/WebKit/WebKit/commit/ab3c0b8cf2a411231da9526614ad5167971dcdd5
Following a discussion on
https://github.com/whatwg/dom/pull/819
There are 3 opened bugs for the spec change.
https://bugzilla.mozilla.org/show_bug.cgi?id=1602200
https://bugs.webkit.org/show_bug.cgi?id=204980
https://bugs.chromium.org/p/chromium/issues/detail?id=1031811
Ryosuke Niwa
Comment 6
2022-10-25 13:52:38 PDT
This is intentional behavior change per
https://github.com/whatwg/dom/pull/819
bigopon.777
Comment 7
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?
Karl Dubost
Comment 8
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.
Ryosuke Niwa
Comment 9
2023-03-09 22:41:13 PST
Pull request:
https://github.com/WebKit/WebKit/pull/11347
EWS
Comment 10
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.
Radar WebKit Bug Importer
Comment 11
2023-03-10 00:31:18 PST
<
rdar://problem/106542160
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug