246899 2022-10-21 23:36:46 -0700 document.adoptNode is a no-op when called on a template element's document fragment 2023-03-10 00:31:18 -0800 1 1 1 Unclassified WebKit DOM Safari 16 All Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=204980 BrowserCompat, InRadar P2 Normal --- 1 huocp rniwa annevk bigopon.777 cdumez karlcow m.goleb+bugzilla rniwa webkit-bug-importer oldest_to_newest 1907505 0 huocp 2022-10-21 23:36:46 -0700 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 ...> 1907583 1 huocp 2022-10-22 15:47:40 -0700 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. 1907622 2 huocp 2022-10-23 02:32:54 -0700 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. 1907623 3 huocp 2022-10-23 02:40:24 -0700 (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. 1907731 4 463188 karlcow 2022-10-23 23:14:59 -0700 Created attachment 463188 testcase for adoptnode Firefox and Chrome return an HTMLHtmlElement object Safari returns `null` 1907735 5 karlcow 2022-10-23 23:46:27 -0700 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 1908223 6 rniwa 2022-10-25 13:52:38 -0700 This is intentional behavior change per https://github.com/whatwg/dom/pull/819 1936333 7 bigopon.777 2023-02-23 14:05:32 -0800 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? 1938393 8 karlcow 2023-03-02 19:52:58 -0800 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. 1940313 9 rniwa 2023-03-09 22:41:13 -0800 Pull request: https://github.com/WebKit/WebKit/pull/11347 1940325 10 ews-feeder 2023-03-10 00:30:13 -0800 Committed 261491@main (dd0a5a2fd2e2): <https://commits.webkit.org/261491@main> Reviewed commits have been landed. Closing PR #11347 and removing active labels. 1940326 11 webkit-bug-importer 2023-03-10 00:31:18 -0800 <rdar://problem/106542160> 463188 2022-10-23 23:14:59 -0700 2022-10-23 23:14:59 -0700 testcase for adoptnode adoptnode-test-case.html text/html 1126 karlcow PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KICA8aGVhZD4KICAgIDxtZXRhIGNoYXJz ZXQ9IlVURi04IiAvPgogICAgPG1ldGEgaHR0cC1lcXVpdj0iWC1VQS1Db21wYXRpYmxlIiBjb250 ZW50PSJJRT1lZGdlIiAvPgogICAgPG1ldGEgbmFtZT0idmlld3BvcnQiIGNvbnRlbnQ9IndpZHRo PWRldmljZS13aWR0aCwgaW5pdGlhbC1zY2FsZT0xLjAiIC8+CiAgICA8dGl0bGU+ZG9jdW1lbnQu YWRvcHRub2RlPC90aXRsZT4KICA8L2hlYWQ+CiAgPGJvZHk+CiAgICA8ZGl2Pjxjb2RlPmZyYWdt ZW50Lm93bmVyRG9jdW1lbnQuZG9jdW1lbnRFbGVtZW50PC9jb2RlPjogPHNwYW4gaWQ9ImxvZzEi Pjwvc3Bhbj48L2Rpdj4KICAgIDxkaXY+VGhlbiA8Y29kZT5kb2N1bWVudC5hZG9wdE5vZGUoZnJh Z21lbnQpOzwvY29kZT48L2Rpdj4KICAgIDxkaXY+PGNvZGU+ZnJhZ21lbnQub3duZXJEb2N1bWVu dC5kb2N1bWVudEVsZW1lbnQ8L2NvZGU+IDxzcGFuIGlkPSJsb2cyIj48L3NwYW4+PC9kaXY+CiAg ICA8c2NyaXB0PgogICAgICBjb25zdCBsb2cxID0gZG9jdW1lbnQucXVlcnlTZWxlY3RvcigiI2xv ZzEiKTsKICAgICAgY29uc3QgbG9nMiA9IGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3IoIiNsb2cyIik7 CiAgICAgIGNvbnN0IGRpdiA9IGRvY3VtZW50LmNyZWF0ZUVsZW1lbnQoImRpdiIpOwogICAgICBk aXYuaW5uZXJIVE1MID0gIjx0ZW1wbGF0ZT48cD48L3A+PC90ZW1wbGF0ZT4iOwogICAgICBjb25z dCBmcmFnbWVudCA9IGRpdi5maXJzdENoaWxkLmNvbnRlbnQ7CiAgICAgIGlmIChmcmFnbWVudC5v d25lckRvY3VtZW50LmRvY3VtZW50RWxlbWVudCA9PT0gbnVsbCkgewogICAgICAgIGxvZzEudGV4 dENvbnRlbnQgPSAibnVsbCI7ICAKICAgICAgfQogICAgICBkb2N1bWVudC5hZG9wdE5vZGUoZnJh Z21lbnQpOwogICAgICBpZiAoZnJhZ21lbnQub3duZXJEb2N1bWVudC5kb2N1bWVudEVsZW1lbnQg PT09IG51bGwpIHsKICAgICAgICBsb2cyLnRleHRDb250ZW50ID0gIm51bGwiOyAgCiAgICAgIH0g ZWxzZSB7IGxvZzIudGV4dENvbnRlbnQgPSBmcmFnbWVudC5vd25lckRvY3VtZW50LmRvY3VtZW50 RWxlbWVudDt9CgogICAgPC9zY3JpcHQ+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==