1712007 - document.adoptNode changes prototype of Custom Element

Status: RESOLVED DUPLICATE of bug 1502814

(Core :: DOM: Core & HTML, defect)

Description

[jridgewell]

Attachment: Test case

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36

Steps to reproduce:

When calling document.adoptNode on a Custom Element that was defined in another document, the node's prototype is reset to the new document's HTMLElement.prototype.

A working demo of the bug can be seen at https://output.jsbin.com/yuwojok/29/quiet

Steps:

1. Create iframe with srcdoc, insert into page
2. Define a new Custom Element (customElements.define('amp-img', class extends HTMLElement {}))
3. Create an instance of the custom element in parent document (const ampImg = document.createElement('amp-img'))
4. Adopt the instance into the iframe's window (iframe.contentDocument.adoptNode(ampImg))
5. Observe the prototype has been changed (Object.getPrototypeOf(ampImg) === iframe.contentWindow.HTMLElement.prototype)

Actual results:

The Custom Element instance's prototype is changed to HTMLElement.prototype of the new document

Expected results:

The Custom Element instance's prototype should remain the same

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It seems that this is not defined behavior.
https://dom.spec.whatwg.org/#concept-node-adopt

Anne, do you have any ideas?

Comment 3

[jridgewell]

Sorry, I forgot to add context links:

This exact issue is discussed at https://github.com/WICG/webcomponents/issues/512, with a resolution at https://github.com/WICG/webcomponents/issues/512#issuecomment-232410812 landing on the "Branching adoption" idea. I believe this was agreed to in https://github.com/WICG/webcomponents/issues/512#issuecomment-233260623 by Anne, with changes landing in https://github.com/whatwg/dom/pull/279 and https://github.com/whatwg/html/pull/1510.

Comment 4

[Alin Ilea, Desktop Test Engineering]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Hi,
I am able to reproduce the issue in release 88, beta 89.0b14 and latest nightly 90.0a1 (2021-05-20) using Windows 10.
This is not a regression, al least not a recent one since I am able to reproduce it in Fx61 as well.
Note that in Chrome the issue is not reproducible.

Thanks for your input.

Comment 5

[Anne (:annevk)]

In part this might date back to the discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 and Firefox still doing prototype changes for normal nodes; also recently discussed in https://github.com/whatwg/dom/issues/977.

But yeah, no prototype changes should happen as part of adopting, precisely because the DOM Standard says nothing about it. (As in, unless the standard says something should happen, it should not happen.)

So yeah, this is something we should change. I'll leave it to Edgar and Olli to prioritize I suppose.

Comment 6

[Edgar Chen [:edgar]]

I will try to fix this in bug 1502814.