|Summary:||window.customElements should be associated with each Window|
|Product:||WebKit||Reporter:||Domenic Denicola <d>|
|Severity:||Normal||CC:||cdumez, koivisto, rniwa, timothygu99, webkit-bug-importer|
|Version:||Safari Technology Preview|
|Bug Depends on:|
Description Domenic Denicola 2017-05-02 13:46:52 PDT
Currently it appears to not be, in three ways: - It gets cleared (set to undefined) when an iframe is removed from the DOM - It gets reset to a new value on navigation from the initial about:blank, even though the Window stays the same during such a navigation - It does not get cleared during document.open(). Per spec this is supposed to create a new Window; non-Firefox browsers do not follow this, but they do generally clear Window-associated stuff, and so we should do the same for window.customElements. Tests at http://w3c-test.org/custom-elements/custom-element-registry/per-global.html
Comment 2 Ryosuke Niwa 2018-08-03 01:03:23 PDT
This stems from the fact neither Blink nor WebKit preserves DOMWindow when navigating from about:blank and doesn't replace DOMWindow upon document.open. This seems quite inconsequential nonetheless.
Comment 3 Domenic Denicola 2018-08-03 07:59:29 PDT
We will likely revert the document.open() tests as part of a general document.open() overhaul led by Timothy Gu (CC'ed), to bring the spec more in line with the simple model used by Chrome and WebKit. For about:blank, the issue is less clear to me, as I was pretty sure that did preserve Window in all browsers... I'm investigating further and will get back to you.
Comment 4 Ryosuke Niwa 2018-08-03 15:19:33 PDT
Great. Let me know what you decide to do.