[whatwg] pushState

[Jonas Sicking]

So to back up. There are a few things that are important to me:

1. The session history (SH) entries created in this way should act
    as much like normal SH entries as possible to the user.
    I.e. the user doesn't care if clicking what looks like a link
    results in a navigation or a .pushState call.
2. That this API allows pages to be written that survives a browser
    restart.
    This is to prevent data loss in case of crash, and to increase
    chances that users install security updates which require restart
    as soon as possible.
3. That the API encourages bug-free pages. I.e. pages that use the API
    'correctly'.

Just 1 in itself means that we can't just kill SH entries just because
the Document they were created from goes away from fastback. If I browse
away from a gmail and see 5 pages in my SH list then I would be very
disappointed if those 5 pages just disappeared because I happened to be
browsing around in another window which ate up the fastback cache.

Similarly, a mobile device might not have a fastback cache at all. It
would look very strange if while i'm staying on the gmail site i'm able
to go 'back' to what to me looks like various different pages. But as
soon as i go to some other site, I loose all those pages and can only go
back directly to the first gmail page.

So we must definitely store the pushed SH data in such a way that if the
Document is recreated the data survives.

This applies whether the URL of my browser changes or not while I'm
doing this browsing. The rendering changing is more important than the
URL changing for a user.


So what I think we should do is to enforce that 'data' is a JSON
serializable object. When a Document is destroyed (due to eviction from
the fastback cache or due to not being cachable) we don't touch the SH
entries associated with that document.

When entering a SH state for which a Document has been destroyed, we
load the URL associated with that SH entry. After the 'load' event for
the Document has fired, and if a data object was provided in the
pushState call for the SH entry, we fire a PopStateEvent event
containing the data stored for the object.

The same thing happens if the user clicks the reload button while on an
SH entry created using pushState. The URL for that entry is loaded and
after the 'load' event has fired, if a data object was provided during
the pushState call, a PopStateEvent is fired with that data.


To minimize the difference between when a SH entry is recovered from the
fastback cache, compared to when the document is reparsed, the Location
object should be changed to reflect the new URL whenever pushState is
called with a url. The advantage of changing the Location object is that
this makes the page behave the same no matter of if it has been reloaded
or not. Setting the Location objects value will cause reloading vs.
scrolling vs. do nothing in the same cases. Similarly reading the
Location will return the same thing no matter of if there has been a
reload or not.


Yes, this is different from how legacy browsers behave. However the
whole point of this API is to improve on the current iframe hacks. If we
didn't there would be no point in adding a new API as it wouldn't be
worth the code fork for users.

Reloads mostly don't work with the iframe hack anyway so you'll end up 
with vastly different behavior no matter what. And if we're not 
considering the reload case then the hashchanged event should be enough.

This isn't a big deal though as far as I can think of. Only if your 
application runs inside someone elses iframe and that outer app is 
intimately interacting with you I can see that it makes a difference. 
This doesn't seem common enough that we should prioritize for it.

/ Jonas