Repository navigation
Contiguous window.name leads to weirdness #6628
Description
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:
- https://static-misc-2.glitch.me/history-adventure/
location.href = '#foo'location.href = '#bar'history.back()location.replace('https://example.com')
This creates 3 history entries:
- https://static-misc-2.glitch.me/history-adventure/
- https://example.com
- 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.
Activity
annevk commentedon Apr 28, 2021
@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.namein A2, going back to A1 will still show the initialwindow.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 commentedon Apr 28, 2021
That'd certainly be easier to spec! I'd put it on the "document state" so it survives reloads, discards etc.
davidben commentedon Apr 28, 2021
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 commentedon Apr 28, 2021
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 commentedon Apr 28, 2021
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 commentedon Jun 9, 2021
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:
…then the name becomes blank. Otherwise, the name is copied from the previous entry.