[whatwg] pushState

[Ian Hickson]

On Fri, 25 Jul 2008, Jonas Sicking wrote:
>
> 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.

Ok. I've used the new "structured clone" concept to sanitise the data and 
make a copy instead of storing the actual object. This enables us to keep 
them around even when the Document is evicted.

One thing I had to change is that now if you go from state 1 to state 3, 
state 2 is no longer popped. You can move discontinuously through the 
states.


> 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.

The timing here is difficult. What should happen if while the page is 
loading, the user navigates to a link with a fragment identifier, or 
invokes pushState, or navigates to another SH entry with a state object?

I'll see what I can come up with. It may be that I'll just delay all 
popstate and hashchanged events until the 'load' event has fired, and then 
I'll fire both for the current state.


> 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.

I just found that I wasn't even updating the Location for fragment 
identifier changes. Oops. I'll fix that and give the behavior you describe 
when I fix bug 6437.

   http://www.w3.org/Bugs/Public/show_bug.cgi?id=6437

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'