-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Contiguous window.name leads to weirdness #6628
Comments
@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 |
That'd certainly be easier to spec! I'd put it on the "document state" so it survives reloads, discards etc. |
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. |
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. |
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. |
Note to myself, the plan is that: If a navigation is same-document, then there's no change to 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. |
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:
location.href = '#foo'
location.href = '#bar'
history.back()
location.replace('https://example.com')
This creates 3 history entries:
…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 awindow.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.The text was updated successfully, but these errors were encountered: