Regression: window.name should not be on navigable

[annevk]

Although #313 obfuscates this somewhat, name targeting happens within a browsing context group. However, it's also that case that using Cross-Origin-Opener-Policy should give you a fresh name (empty string). In combination this means that name should not have moved to navigable.

There's existing tests around COOP for this. Did you end up testing the opposite somewhere?

[domenic]

We did not change any tests here.

I believe what we have in the spec today matches implementations, or at least, matches consensus on where implementations want to go. (E.g. maybe we clear the name a bit more often than implementations do; I recall some discussion of that.) Do you have a specific case where you were able to run through the spec and get a wrong answer?

Nevertheless, I am sympathetic with the idea that, if these things should not carry over across BCG switches, it's simpler to store the property on BCs, than it is to store the property on navigables and change it across BCG switches.

@jakearchibald, do you remember why we put this on navigable? I know we spent some time working out exactly when and how to clear the name, but I can't remember why we originally moved it.

Some issues we closed: #5350, #6628. The latter looks particularly related.

[annevk]

In particular I'm thinking of this test expectation:

assert_equals(payload.name, hasOpener ? channelName : "", 'name');

That whenever we sever the opener (due to replacement), name is also reset. Note that this can happen even when the two documents are same origin.

Now furthermore, I see now that "apply the history step" clears it across origins always. It's not clear to me that clearing the name for auxiliary browsing contexts in that matter is web compatible. I don't think that's something any user agents do or have active plans to do.

[annevk]

It does make sense to store it on document state, but clearing and scoping still seems like a partial browsing context affair to me.

[domenic]

Now furthermore, I see now that "apply the history step" clears it across origins always. It's not clear to me that clearing the name for auxiliary browsing contexts in that matter is web compatible. I don't think that's something any user agents do or have active plans to do.

The full conditions are

• navigable's parent is null;
• targetEntry's document's browsing context is not an auxiliary browsing context whose disowned is false; and
• targetEntry's document's origin is not oldOrigin

So it's more strict than that. It looks like that was working to reflect #6628 (comment).

[annevk]

Apologies, I somehow read over that. So the main issue here is not clearing when the top-level browsing context changes. Which also seems to be something that might not have been actively considered as being part of the existing setup.

[jakearchibald]

Yeah, the aim was to spec #6628 (comment).

So the main issue here is not clearing when the top-level browsing context changes.

Should it be cleared?

As far as I understand, carrying script-visible state across BCs is not a problem if they're same origin. We don't partition localstorage/sessionstorage, so I don't see why we'd have a special behaviour for window.name.

[annevk]

Well, name is part of how you can get a reference to a BC and since the whole point of COOP is to prevent references, clearing it makes sense.

[jakearchibald]

Fair enough. I guess I was thinking, even if it has the same name, it's in a different 'scope', so it's fine. But clearing it seems fine too.

I was focusing on window.name as a cross-origin data leak.