Make window.name deal with lack of browsing context

[annevk]

Tests: web-platform-tests/wpt#15391.

Helps with #4363.

---

/window-object.html ( diff )

[domenic]

As discussed in IRC, this reveals some fractal brokenness.

The current spec seems to assume that there is always a strong reference from Window -> BC. Discarding only removes the strong reference from UA -> BC; if some script holds a JS -> Window reference, then BC stays alive.

The tests in web-platform-tests/wpt#15391 indicate, however, that window.name returns the empty string (and thus, setting is a no-op) for any Window attached to an iframe that was .remove()ed. So this PR is indeed doing something right.

I see two ways forward:

1. Discarding a BC (mostly visible by .remove()ing iframes? also window.close() and manual window closes) should null out the Window -> BC reference. Then this PR is good as-is, although there are other parts of the spec that are probably broken and inconsistent (e.g. window.closed checks whether the BC was discarded).
2. This PR should switch from branching on "Window doesn't have a BC" to "Window's BC was discarded". This would be consistent with the existing spec, but the existing spec is on shaky ground. There is no "discarded" boolean yet; that's a bit hand-wavey. And the notion of there being a Window -> BC link that exists but we always (usually?) guard with an "is discarded" check is annoying.

I lean toward (1), with follow-up work being to guard all Window -> BC references with a null check. But, I am a bit scared that we have this long-standing assumption in the spec of an always-existing Window -> BC link. I'd love to hear from folks like @bzbarsky and @jdm.

Somewhat-related: #1279 #4076 #1073

[domenic]

Oh, well, it turns out the spec doesn't seem to have any definition of a Window -> BC pointer, only a document -> BC pointer. It assumes and uses a Window -> BC pointer a lot. But in #4363 (comment) @annevk suggests defining "Window's BC" to be "Window's associated document's BC", or null if Window has no associated document.

I'm unsure what the implications would be there, as I can't immediately see if "discard" severs the Document -> BC relationship. But, it's something to consider.

[jdm]

https://html.spec.whatwg.org/multipage/window-object.html#a-browsing-context-is-discarded seems to say that the document's BC relationship would be severed but other references to the BC remain valid.

[annevk]

FWIW, I think this is a variation on #3846 and I think as @bzbarsky says there we need null checks. Or we need a flag and then check for that flag, but null seems much cleaner and easier to spot mistakes with.

[annevk]

Note also that the specification already has this:

And the Document originally created for an iframe element, which has since been removed from the document, has no associated browsing context, since that browsing context was discarded.

[domenic]

With #4368 as a foundation I'm happy with (1). It looks like that makes it properly clear that after discarding, a Document's BC and thus the Window's BC is null.