Unclear what location.href of iframe should be after frame becomes disconnected #3959

TimothyGu · 2018-08-23T21:08:09Z

<body>
<script>
  const frame = document.body.appendChild(document.createElement("iframe"));
  const win = frame.contentWindow;
  const loc = win.location;
  frame.remove();
  try {
    alert("String(loc): " + String(loc));
  } catch (err) {
    alert("String(loc) err: " + err);
  }
  try {
    alert("loc.href: " + loc.href);
  } catch (err) {
    alert("loc.href err: " + err);
  }
  try {
    alert("Type(win.location): " + Type(win.location));
  } catch (err) {
    alert("Type(win.location) err: " + err);
  }
  try {
    alert("win.location.href: " + win.location.href);
  } catch (err) {
    alert("win.location.href err: " + err);
  }

  function Type(x) {
    if (x === null) return "null";
    return typeof x;
  }
</script>

In table form:

Browser	`String(loc)`	`loc.href`	`Type(win.location)`	`win.location.href`
Chrome	`TypeError`	`undefined`	`"object"`	`undefined`
Edge	`"about:blank"`	`"about:blank"`	`TypeError`	`TypeError`
Firefox	`""`	`""`	`"object"`	`""`
Safari	`TypeError`	`undefined`	`"null"`	`TypeError`
Spec(?)	??	??	`"object"`	??

This issue amazes even me in its number of ways browsers find to disagree with each other. I am also not entirely sure what the spec currently says, and what I put in that row is my best understanding. The ?? refers to the fact that the definition of Location object's relevant Document seems to be broken for a Location associated with a Document object that no longer has a browsing context.

The text was updated successfully, but these errors were encountered:

annevk · 2018-08-24T09:09:22Z

It seems weird that loc and win.location would be different objects. You didn't test that explicitly, but I think they should remain 1:1 per the standard.

It does seem to me that the active document pointer should remain on the browsing context. But we should account for the browsing context not being there and haven't.

I like using "about:blank" as URL in that case for the getters (matches the default URL we use in a number of places) and have the setters throw. Given the wide disagreement between implementations that's hopefully web compatible.

@bzbarsky might want to comment on this when he's back from a break.

cdumez · 2018-09-28T20:15:38Z

It would really be great if we could align browsers here indeed. I am happy to help on the WebKit side.

bzbarsky · 2018-10-08T18:14:28Z

You didn't test that explicitly, but I think they should remain 1:1 per the standard.

So at least in Firefox, the Location object lives on the Window, which makes some sense. The browsing context going away doesn't affect this. But for other Window members it definitely does (for example, .navigator changes identity when the browsing context goes away, or when the Window stops being the current window in the browsing context, because that object is lazily-created (as is Location) and we clear out a bunch of cached state on the window at those points.

There's a tension here between keeping everything alive forever and cleaning things up when pages are torn down due to browsing context destruction or navigation... I really don't know the best thing to do here spec-wise that all browsers might agree on. :(

It does seem to me that the active document pointer should remain on the browsing context.

The browsing context goes away in this specific iframe.remove() case, no? https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element says:

When an iframe element is removed from a document, the user agent must discard the element's nested browsing context, if it is not null, and then set the element's nested browsing context to null.

which links to https://html.spec.whatwg.org/multipage/window-object.html#a-browsing-context-is-discarded which as far as I can tell drops references to the browsing context. And that explicitly calls out WindowProxy as not keeping browsing contexts alive.

But we should account for the browsing context not being there

Yeah.

I like using "about:blank" as URL in that case for the getters and have the setters throw.

I'd like to see a test of what setters do right now. I do think Firefox already throws some weird non-spec exception in this case, which makes me pretty hopeful that throwing is web-compatible. If so, then this plan seems OK to me.

annevk · 2018-10-09T13:30:14Z

Getters and setters

In Safari win.location and loc are not equal, the former is null instead. In both Chrome and Safari the setters are no-ops and the getters return undefined.

In Firefox .href throws (weird non-spec exception), other setters are no-ops, and all getters return the empty string.

Given these results, it seems we need early exits for both setters and getters dealing with the browsing context being missing. No-ops for setters and values matching up with about:blank for getters seem most reasonable to me now. I think we should maintain win.location equaling loc here.

Methods

.reload() is undefined in Chrome and Safari (and therefore throws when invoked), no-op in Firefox. assign() and replace() throw in Firefox, are a no-op in Chrome, and undefined in Safari (and therefore throws when invoked).

Making these all no-ops as well seems safest to me.

Misc

(General lifetime issues of these globalish objects is being tracked by #2545, #2566, and #3267.)

It does seem to me that the active document pointer should remain on the browsing context.

FWIW, the reason I mentioned this is because I briefly considered whether Location's "relevant Document" should be defined in terms of something other than browsing context's active document. It seems instead that everything that uses "relevant Document" should only do so when there is in fact a browsing context.

For whatwg/html#3959.

annevk · 2018-10-09T13:58:51Z

I created web-platform-tests/wpt#13435 to encode the aforementioned expected results in wpt. I'll also work on a patch for the HTML Standard. Unfortunately, it seems that each affected algorithm will gain one additional branch at the beginning. If anyone has better ideas please let me know.

Tests: web-platform-tests/wpt#13435. Fixes #3959.

annevk · 2018-10-18T10:05:17Z

Note that I created a proposal for this as well at #4076. It basically is awaiting review and some amount of implementer buy-in.

Tests: web-platform-tests/wpt#13435. Fixes #3959.

Previously, the various pieces of spec text here assumed that a browsing context always existed. Tests: web-platform-tests/wpt#13435. Fixes #3959.

For whatwg/html#3959 and whatwg/html#4076.

cdumez · 2018-11-01T17:01:36Z

In Firefox, Chrome and Safari, if you go to "about:blank" and print location.pathname, it will be "blank". Not sure it this is expected or not but I thought I'd point it out, especially considering the new WPT expect the the pathname to be "" when the location's browsing context is gone, even though it's href is "about:blank".

cdumez · 2018-11-01T17:18:44Z

I asked Alex (who is our URL expert) and he seems to agree that "blank" should be the expected path name when the URL is "about:blank". If so, I think the WPT test that was added for this spec change needs to be updated to expect the pathname to be "blank" when the Location's browsing context is gone.

cdumez · 2018-11-01T17:29:20Z

web-platform-tests/wpt#13854

annevk · 2018-11-02T08:36:42Z

Thanks, sorry for that!

…estonly Automatic update from web-platform-testsTest Location sans browsing context For whatwg/html#3959 and whatwg/html#4076. -- wpt-commits: fce65ebd7656136f5f8452378146f1b7af30bf79 wpt-pr: 13435

Previously, the various pieces of spec text here assumed that a browsing context always existed. Tests: web-platform-tests/wpt#13435. Fixes whatwg#3959.

…estonly Automatic update from web-platform-testsTest Location sans browsing context For whatwg/html#3959 and whatwg/html#4076. -- wpt-commits: fce65ebd7656136f5f8452378146f1b7af30bf79 wpt-pr: 13435 UltraBlame original commit: 21440047222db956d995cb518b57b2b3272126e0

TimothyGu changed the title ~~Unclear what history.href of iframe should be after frame becomes disconnected~~ Unclear what location.href of iframe should be after frame becomes disconnected Aug 23, 2018

TimothyGu mentioned this issue Aug 23, 2018

HTML: document.open() and document's URL web-platform-tests/wpt#12636

Merged

TimothyGu added the topic: location label Aug 23, 2018

domenic added the interop Implementations are not interoperable with each other label Aug 23, 2018

annevk added a commit to web-platform-tests/wpt that referenced this issue Oct 9, 2018

Test Location sans browsing context

d144d71

For whatwg/html#3959.

annevk mentioned this issue Oct 9, 2018

Test Location sans browsing context web-platform-tests/wpt#13435

Merged

annevk added a commit that referenced this issue Oct 9, 2018

Make the Location object deal when it does not have a browsing context

356fd38

Tests: web-platform-tests/wpt#13435. Fixes #3959.

annevk mentioned this issue Oct 9, 2018

Make the Location object deal when it does not have a browsing context #4076

Merged

annevk added a commit that referenced this issue Oct 30, 2018

Make the Location object deal when it does not have a browsing context

65e8ff7

Tests: web-platform-tests/wpt#13435. Fixes #3959.

domenic closed this as completed in #4076 Oct 31, 2018

domenic pushed a commit that referenced this issue Oct 31, 2018

Make the Location object deal when it does not have a browsing context

8ef0102

Previously, the various pieces of spec text here assumed that a browsing context always existed. Tests: web-platform-tests/wpt#13435. Fixes #3959.

domenic pushed a commit to web-platform-tests/wpt that referenced this issue Oct 31, 2018

Test Location sans browsing context

fce65eb

For whatwg/html#3959 and whatwg/html#4076.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unclear what location.href of iframe should be after frame becomes disconnected #3959

Unclear what location.href of iframe should be after frame becomes disconnected #3959

TimothyGu commented Aug 23, 2018 •

edited

Loading

annevk commented Aug 24, 2018 •

edited

Loading

cdumez commented Sep 28, 2018

bzbarsky commented Oct 8, 2018

annevk commented Oct 9, 2018

annevk commented Oct 9, 2018

annevk commented Oct 18, 2018

cdumez commented Nov 1, 2018

cdumez commented Nov 1, 2018

cdumez commented Nov 1, 2018

annevk commented Nov 2, 2018

Unclear what location.href of iframe should be after frame becomes disconnected #3959

Unclear what location.href of iframe should be after frame becomes disconnected #3959

Comments

TimothyGu commented Aug 23, 2018 • edited Loading

annevk commented Aug 24, 2018 • edited Loading

cdumez commented Sep 28, 2018

bzbarsky commented Oct 8, 2018

annevk commented Oct 9, 2018

Getters and setters

Methods

Misc

annevk commented Oct 9, 2018

annevk commented Oct 18, 2018

cdumez commented Nov 1, 2018

cdumez commented Nov 1, 2018

cdumez commented Nov 1, 2018

annevk commented Nov 2, 2018

TimothyGu commented Aug 23, 2018 •

edited

Loading

annevk commented Aug 24, 2018 •

edited

Loading