Contiguous window.name leads to weirdness

[jakearchibald]

https://html.spec.whatwg.org/multipage/browsing-the-web.html#traverse-the-history 4.2.1 and 4.4.2 refer to updating history entries that are 'contiguous' same-origin.

However, it's possible to have two non-contiguous entries that share a document:

1. https://static-misc-2.glitch.me/history-adventure/
2. location.href = '#foo'
3. location.href = '#bar'
4. history.back()
5. location.replace('https://example.com')

This creates 3 history entries:

1. https://static-misc-2.glitch.me/history-adventure/
2. https://example.com
3. https://static-misc-2.glitch.me/history-adventure/#bar

…where 1 and 3 can share a document. In Firefox, you can pass from 1, to 2, to 3, and be given the same document you saw in step 1. In other browsers, you can pass between 1 & 3 (eg go(2)) without the document reloading.

However, in Firefox, if you start in 1, and set window.name, then go to 2, then 3, window.name is now an empty string. If you start in 1, then go straight to 3, window.name is not changed.

Since 1 and 2 are the same document, the change in window.name is observable by script. It seems weird for the browser to change this value during the lifetime of a document.

Proposal: It's decided if one history entry should share a window.name with another at entry creation time (basically, depending on whether the preceding history entry is same-origin), and this remains true throughout the existence of the history entry. It may be split from other entries in edge-cases like above, but it's consistent with how history entries can share documents.

Alternatively, window.name could be scoped per navigable per origin, so if you navigate from origin A, to B, to C, to A, the two origin A entries will share a window.name, kinda similar to how they share session storage, although session storage is shared with iframes, which wouldn't be the case here. This seems easier to understand, however it's a bigger change from what Safari and Firefox do today.

[annevk]

@artines1 thoughts?

(I vaguely wonder if we could try scoping it even more so that if you go from document A1 to A2 and then set window.name in A2, going back to A1 will still show the initial window.name. Something to the effect of it being stored on a document and copied to (not shared with) the subsequent document after a same-origin navigation.)

[jakearchibald]

That'd certainly be easier to spec! I'd put it on the "document state" so it survives reloads, discards etc.

[davidben]

Agreed that this is a nicer model. Hopefully no one's relying on weird edge cases around back/forward like that, but I guess we'd have to try it to find out.

[jakearchibald]

It'd break cases where folks are trying to use it like a per-frame session storage, but I don't know how common that is.

[artines1]

I think the weirdness is coming from the unclear definition of the continuity of history entries. Maybe we should make a clear definition that can handle the edge cases here.

[jakearchibald]

Note to myself, the plan is that:

If a navigation is same-document, then there's no change to window.name. The name is stored along with the document state, so it's the same data source.

For a cross-document navigation, if either of the following is true:

• New document is a different origin to previous document, and the bc is a top level bc, but not an aux bc.
• New history entry's browsing context is in a different session.

…then the name becomes blank. Otherwise, the name is copied from the previous entry.