window.opener can be cleared

[annevk]

It turns out that browsers clear the opener browsing context once that's closed/discarded (see #4428; needs testing). I.e., if a child bc opens an auxiliary bc and the child bc gets closed/discarded, when does auxiliary bc's opener browsing context change to null? (Thanks Nika for pointing this out!)

cc @mystor @bzbarsky

[annevk]

It seems we can make it null at discard-time. The remaining question is how. Do we track all openees with a non-null opener browsing context so that when discarding happens we can clear all openees's opener browsing context? It seems like that should work?

[bzbarsky]

Conceptually, you could do that, or you could just check at opener-get time whether the opener browsing context is discarded, right? At least as long as we're talking about the script-visible opener. If spec algorithms examine opener directly in some way, things are more complicated.

[annevk]

There are indeed algorithms that examine opener directly. I suspect those are wrong (instead those need to operate on a browsing context group and its top-level browsing contexts). Perhaps we ought to fix #313 first to make sure of that though.

And currently discarded is not a state we expose on a browsing context as the assumption is that all references to it are cleared at the same time. I guess exposing the discarded state is probably a better strategy than all the additional bookkeeping my solution would take.

[annevk]

I forgot to add this here: I think the main problem with checking when getting is that then "opener browsing context" would have to hold a weak reference to a browsing context (since we prefer the specification to not have memory leaks these days) as well as a browsing context needing this additional state in case it's discarded, but not "freed".

Preferences anyone?

[domenic]

I'm not sure I'm fully following but I think your original proposal is pretty straightforward. It would still be a weak reference in that direction, I think, but the architecture just makes sense. It's easy to understand the intent of the spec that way.

But I'm also OK putting this off until work on #313 is done or similar, and then perhaps working on a script-visible-only solution.