opener attribute setter and disowning

[gterzian]

Question on the "attribute setter" part of https://html.spec.whatwg.org/multipage/browsers.html#navigating-auxiliary-browsing-contexts-in-the-dom

If the given value is null, then disown the current browsing context and return.

While in the process of writing some tests for that in the context of servo/servo#20678, I noticed that if you store window.opener in a variable, and then do window.opener = null, per the spec it should 'disown' the BC, however the stored opener in the other variable still "works", and allows you to navigate the creator and so on. Manual testing in FF and Chrome shows this behavior seems prevalent.

So disowning doesn't seem to have an effect beyond making opener being null.

So one can wonder if there is really a difference between Step 1, and Step2, which is:

Return the result of calling OrdinaryDefineOwnProperty(this Window object, "opener", { [[Value]]: the given value, [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true }). Rethrow any exceptions.

In practice, whether you set the opener to null or test, if you haven't stored a reference to the opener it seems you've lost it anyway, and if you did store it, whether the BC is 'disowned' or not doesn't seem to matter beyond what is accessible via opener.

Should we either drop this Step 1, or try to remove what seems like a loophole?

I can imagine this could matter if a script on a page wanted to guarantee all relation with a potential opener would have been severed, for example to prevent other scripts from accessing it, in the current situation it's impossible to know if opener would have been accessed and stored to another variable by another script before that script would have a chance to do opener = null.

[rniwa]

@cdumez

[annevk]

I think the main thing this should affect is link targeting (#313).

[annevk]

Resolving this as a duplicate of #313, as you're completely correct that the current text doesn't provide any guarantees.