Bug 171567

Summary:

window.customElements should be associated with each Window

Product:

WebKit

Reporter:

Domenic Denicola <d>

Component:

DOM

Assignee:

Nobody <webkit-unassigned>

Status:

NEW

Severity:

Normal

CC:

ahmad.saleem792, ap, bfulgham, cdumez, esprehn+autocc, ews-watchlist, japhet, kangil.han, koivisto, kondapallykalyan, rniwa, timothygu99, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

Safari Technology Preview

Hardware:

Unspecified

OS:

Unspecified

URL:

https://wpt.fyi/results/custom-elements/custom-element-registry/per-global.html?label=experimental&label=master&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2023-webcomponents

Bug Depends on:

Bug Blocks:

154907

Attachments:

Description	Flags
WIP	ews-feeder: commit-queue-
WIP2	ews-feeder: commit-queue-

Domenic Denicola

Reported 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

Attachments
WIP (6.19 KB, patch) 2023-01-31 22:17 PST, Ryosuke Niwa	ews-feeder: commit-queue-	Details Formatted Diff Diff
WIP2 (8.37 KB, patch) 2023-02-06 18:22 PST, Ryosuke Niwa	ews-feeder: commit-queue-	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Radar WebKit Bug Importer

Comment 1 2017-05-08 21:20:33 PDT

<rdar://problem/32067854>

Ryosuke Niwa

Comment 2 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.

Domenic Denicola

Comment 3 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.

Ryosuke Niwa

Comment 4 2018-08-03 15:19:33 PDT

Great. Let me know what you decide to do.

Ahmad Saleem

Comment 5 2022-08-19 14:44:30 PDT

Safari Technology Preview 151 is failing on following test from test case in Comment 0: Navigating from the initial about:blank must not replace window.customElements Similarly, Chrome Canary 106 also fail on same, while Firefox Nightly 105 pass all tests. Thanks1

Ryosuke Niwa

Comment 6 2023-01-31 22:17:56 PST

Created attachment 464791 [details] WIP

Ryosuke Niwa

Comment 7 2023-02-06 18:22:55 PST

Created attachment 464881 [details] WIP2

Note You need to log in before you can comment on or make changes to this bug.