[whatwg] pushState

Ian Hickson wrote:
> On Tue, 29 Jul 2008, Jonas Sicking wrote:
>> I'll check with the ECMA Script folks, but this one might be an 
>> alternative to link to:
>>
>> http://wiki.ecmascript.org/doku.php?id=es3.1:json_support
>>
>> State that the object passed as 'data' is passed to JSON.parse with the 
>> second argument not specified. Any exception thrown is forwarded out to 
>> the caller of pushState as usual.
> 
> Interesting, thanks. Doesn't really define it clearly though. :-(
> 
> 
>>>> 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.
>>> How would this work with bookmarking?
>> Just as specified (or at least intended) in the spec right now.
>>
>> Say that the user starts on page1.html
>>
>> <bookmark>   (bookmarks page1.html)
>> pushState("title", "data")
>> <bookmark>   (bookmarks page1.html)
>> pushState("title", "data", "page2.html")
>> <bookmark>   (bookmarks page2.html)
>>
>> Additionally, a UA is free to add the ability to store the data 
>> parameter in its bookmark storage. For example firefox under some 
>> circumstances flags URIs in the bookmark store as POST URIs, i.e. they 
>> should be fetched with POST rather than GET (this is specifically for 
>> search engine bookmarks). Similarly the data can be stored alongside the 
>> URI for the bookmark, however this is optional, just like the fastback 
>> cache.
> 
> The problem I have with this is that it increases the number of possible 
> user-visible behaviours and failure scenarios:
> 
>  - same Document, script knows how to handle data.
>  - different Document, script knows how to handle data.
>  - same URL, different Document, data ignored.
>  - different URL, different Document, script knows how to handle data,
>    but copying URL fails to work as expected.
>  - different URL, different Document, data ignored.

I'm actually more worried about the URL thing causing bugs than the data 
thing.

* To avoid bad user experience behavior the site has to send almost
   exactly the same markup for both URLs, i.e. both for the page that
   called pushState, and for the page served for the URL in the URL
   argument in the pushState call.
* Entering a URL that is results in a 404 (or any other non-succcess
   value). This works fine when pushState is called, but fails on reload.

This applies no matter which solution we choose for the data parameter.

Additionally, if we allow the data parameter to be preserved across 
Document recreations there is also:
* Both URLs have to react the same way when a popstate event is fired.

However all these can be seen as variants of the first bullet. If the 
page serves the same markup it wouldn't be a 404, and it should deal 
fine with the popstate event.

In other words. If a page uses pushState to transition from
https://bugzilla.mozilla.org/show_bug.cgi?id=123456
to
https://bugzilla.mozilla.org/show_bug.cgi?id=321321
then things are likely to work fine. However if a page tries to use 
pushState to transition between
https://bugzilla.mozilla.org/show_bug.cgi?id=123456
and
https://bugzilla.mozilla.org/query.cgi
then the risk of something going wrong is quite big. I think this will 
be true no matter if the data parameter is supported or not.

So I think we should either drop the URL argument entirely and say that 
URL transitions are too risky. Or we should leave the spec as is (but 
require that data is serializeable) and just encourage people not to 
transition between wildly different pages.

Personally I think keeping the URL is fine. We can never entirely 
prevent pages from having bugs. But instead encourage the safe 
transitions, and always use safe-looking transitions in examples in the 
spec.

/ Jonas

Received on Sunday, 3 August 2008 13:47:24 UTC