History entry state (history & appHistory) and error documents

[jakearchibald]

I'm trying to spec how error documents work and ran into this:

1. Go to a page that doesn't work offline.
2. Run history.replaceState({ foo: 'bar' }, '', '').
3. Go offline & refresh to get an error page.
4. Go online & refresh to get the original page.

What is history.state?

Chrome & Safari: null.
Firefox: { foo: 'bar' }.

Firefox's behaviour seems to make the most sense here. A temporary error shouldn't result in the loss of history state.

However, in #6213 (comment) we saw that redirects during a reload do clear history state. I'm not sure if appHistory wants to do the same (cc @domenic), but it definitely needs be cleared on cross origin redirects.

Error pages are a different origin, but does it make sense to carve out some kind of exception in the spec to avoid clearing history state in this case?

[domenic]

I don't like carving out exceptions much myself.

Clearing the state makes more sense to me here; when you get an error page, reload, and get a new page, that feels like a fresh navigation, and not like any kind of session restore where the state would be carried over.

[jakearchibald]

Even if the reload is done by the browser itself? (at least Chrome does this for the offline case)

In case it changes your mind, we don't clear POST data in this case.

[domenic]

Bleh. I mean, in my opinion that should not make a difference, and reloading from an error page (either user or browser initiated) should just be a fresh load. That's conceptually clean and seems fine for users who would expect a fresh start IMO.

But if all browsers treat that as a special case and retain state/POST data/etc., then I guess we should add a special case of that sort.

[annevk]

When discussing this on Matrix I tended towards Domenic's initial position, but I think it's fair to say that for error pages the behavior Jake is suggesting is better for users, especially in the context of a session. Although not the case for every session, most sessions are short-lived and so a network error is more likely a connection issue than anything else. For users it seems more useful to preserve history data in those cases.

[jakearchibald]

I think we can draw a meaningful line here:

When there's a redirect on traversal, we fully change the document state, so it makes sense to clear the history state at the same time. By "fully change the document state", I mean that if 3 history entries are sharing the same document, if there's a redirect on traversal then just that one history entry changes document state – it breaks away from the rest.

When there's a traversal that results in a null origin document (sandbox), or an error page, it just sets the document, it doesn't change the document state. In this case I think we should keep the history state, but prevent the null origin document (or error page) from accessing or modifying that state.

[annevk]

I'm less certain about sandboxing myself as that seems like an intentional act to change the nature of the document.

[jakearchibald]

I guess it comes down to this:

1. //origin1/foo
2. //origin1/foo#bar
3. //origin1/foo#secret

If you're on entry three, and reload, and it switches to sandboxed, should that page see foo#secret?

If the user clicks back, will it be a document swap, or a simple fragment navigation?