New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 717715 link

Starred by 3 users
Status: Available
Owner: ----
Cc:
yukishiino@chromium.org
█ dominicc@chromium.org
dcheng@chromium.org
bashi@chromium.org
domenic@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 149785

Show other hotlists

Hotlists containing this issue:
document.open


Sign in to add a comment

window.customElements should be associated with each Window

Project Member Reported by domenic@chromium.org, May 2 2017 
Currently it appears to not be, in two ways:

- It gets cleared 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 by dominicc@chromium.org, May 8 2017

Cc: bashi@chromium.org dcheng@chromium.org dglazkov@chromium.org
Is there a metabug for this? There's lots of window properties which get reset on navigation:

origin and other properties which hang off the document in implementation
screen
history
locationbar
menubar (but not personalbar?!)
scrollbars
statusbar
toolbar
navigator
styleMedia
appcache

Follow the breadcrumbs back from LocalDOMWindow::Reset.

Who owns that code? It gets into frames and navigations a lot. I think this is one area of the codebase which is twisty and still relies on very busy heroes.

Comment 2 by bashi@chromium.org, May 8 2017

Cc: yukishiino@chromium.org

Comment 3 by dcheng@chromium.org, May 8 2017 

LocalDOMWindow::Reset() should only get called if we install a new Window object: this should be skipped if this is navigation from the initial about:blank page, and the navigation is same origin.

(Another surprising failure is the failure in issue 718363, which I naively wouldn't have expected, but I haven't looked at it in detail yet)

Comment 4 by tkent@chromium.org, Jul 14 2017

Blockedon: 149785
Status: Available (was: Untriaged)

Comment 5 by tkent@chromium.org, Feb 7 2018

Cc: -dglazkov@chromium.org
A section for the first bullet.

https://html.spec.whatwg.org/multipage/browsing-the-web.html#initialise-the-document-object
> 1. If browsingContext's only entry in its session history is the about:blank Document that was added when browsingContext was created, and navigation is occurring with replacement enabled, and that Document has the same origin as the new Document, then do nothing.

Edge and Firefox works correctly.
►

Sign in to add a comment