Bug 171567

Summary: window.customElements should be associated with each Window
Product: WebKit Reporter: Domenic Denicola <d>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: cdumez, koivisto, rniwa, timothygu99, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 154907    

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 1 Radar WebKit Bug Importer 2017-05-08 21:20:33 PDT
<rdar://problem/32067854>
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.