New issue
Advanced search Search tips

Issue 778318 link

Starred by 3 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug



Sign in to add a comment

Window object not inherited if iframe src is set dynamically

Project Member Reported by dcheng@chromium.org, Oct 25 2017

Issue description

Per the spec (https://html.spec.whatwg.org/multipage/browsing-the-web.html#initialise-the-document-object), the window object should be inherited for same-origin navigations from the initial about:blank Document.  For example, https://iframe-global-retain.glitch.me/ demonstrates that this works in Chrome.

However, https://iframe-global-retain.glitch.me/firefox-only.html shows an example where this doesn't happen in Chrome (but works in Firefox). This is a bug.
 

Comment 1 by dcheng@chromium.org, Oct 25 2017

Cc: haraken@chromium.org
Cc: jakearchibald@chromium.org yukishiino@chromium.org
Status: Started (was: Assigned)
Also see the spec bug https://github.com/whatwg/html/issues/3267. For now I think I'll try to move the Chrome behavior a bit closer to the Firefox behavior, because our current behavior makes no sense.

Comment 3 by dcheng@chromium.org, Jan 17 2018

Cc: skyos...@chromium.org
I poked at this a bit. It turns out to be quite tricky to fix.

The issue is we actually create the initial empty document when we first create a LocalFrame, in FrameLoader::Init().

However, when creating a new frame or window, we then immediately navigate it about:blank if no URL was specified. The navigation commit logic sees this and duly notes that we navigated from the initial empty document (created in FrameLoader::Init), thus we should mark it as having committed a real load.

But we didn't really want that--we're still on the initial empty document. In essence, we navigated to the initial empty document... twice.

Here's where it gets complicated:
- I believe there is extensions code that depends on seeing the notifications for loading a document when inserting an <iframe> with no source. This code currently depends on seeing the notifications from the second initial empty document.
- LocalFrameView::BeginLifecycleUpdates is tied to whether or not the initial empty document is being displayed. If it is, the frame remains throttled.
- Thus, if we simply fix the frame loader state machine to accurately reflect that the frame is still on the initial empty document, we break renderer pipeline unthrottling for the display:none hack (and possibly other cases).
- However, if we remove the BeginLifecycleUpdates check in LocalFrameView, we won't defer commits for the initial real navigation of an <iframe> (e.g. inserting <iframe src="https://example.com/"> should defer commits).

Ultimately, I think we probably don't want to load two documents every time we only need to load the initial empty document. We'll need to:
- figure out how to generate the notifications that webRequest expects to listen to
- no longer throttle the initial empty document even if there's a navigation queued
- use the normal navigation logic to defer commits if there is a pending initial navigation to avoid FOUC
Components: -Blink>DOM Blink>Internals
Window object => core/frame/dom_window.h => Blink>Internal as per core/frame/OWNERS

Sign in to add a comment