[whatwg] Proposed changes to the History API

[Justin Lebar]

On Thu, Aug 20, 2009 at 11:20 AM, Jeremy Orlow<jorlow at chromium.org> wrote:
> I see.  It makes more sense why you mentioned the session storage element
> then.  Note that there has been some discussion about whether session
> storage should survive crashes, but I know Safari and Chrome are currently
> planning to _not_ serialize it to disk.

I just did a quick test, and it appears that Firefox does save
sessionStorage across browser sessions, but IE8 does not.

Leaving aside the question of what the right thing to do is with
sessionStorage, I think there are some serious benefits to saving the
pushState'ed state across sessions.  Suppose I'm using a webmail
client which uses this new API.  I click around to a few of my folders
and messages and then close the browser.

If the page wants the back/forward buttons to work when the browser
re-opens, it needs to store all of the state for those history entries
in the URI.  At the point that pages have to do that, we might as well
not store a per-page state object.

>  I still think we shouldn't force app developers to serialize everything to
> strings.  Maybe we can just raise an exception if they try to set the
> history state to something unserializable?  (I guess that's what you're
> already doing?)

Right now, I just serialize to JSON and throw an exception if that
fails.  I don't have a problem continuing to do that, at least until
we get the structured clone thing sorted out.

-Justin

> On Thu, Aug 20, 2009 at 11:05 AM, Justin Lebar <justin.lebar at gmail.com>
> wrote:
>>
>> On Wed, Aug 19, 2009 at 5:31 PM, Jeremy Orlow<jorlow at chromium.org> wrote:
>> > but here it seems like everything can just stay in memory...right?
>>
>> My thought was that if you had a tab open and restarted the browser,
>> that the state objects would be there after the restart, so we'd have
>> to serialize to disk.  I also thought that we'd persist this state
>> data even after we take a Document out of memory.
>>
>> It might be possible to store some subset of DOM objects while still
>> meeting those requirements, but that seems like it might be a serious
>> can of worms.  Do you have a use case which would be facilitated by
>> being able to store some DOM objects in this way?
>>
>> -Justin
>
>