<div class="gmail_quote">On Thu, Aug 20, 2009 at 3:13 PM, Justin Lebar <span dir="ltr"><<a href="mailto:justin.lebar@gmail.com">justin.lebar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Aug 20, 2009 at 11:20 AM, Jeremy Orlow<<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
> I see. It makes more sense why you mentioned the session storage element<br>
> then. Note that there has been some discussion about whether session<br>
> storage should survive crashes, but I know Safari and Chrome are currently<br>
> planning to _not_ serialize it to disk.<br>
<br>
</div>I just did a quick test, and it appears that Firefox does save<br>
sessionStorage across browser sessions, but IE8 does not.<br>
<br>
Leaving aside the question of what the right thing to do is with<br>
sessionStorage,</blockquote><div><br></div><div>The spec makes it clear that it's possible, but isn't session (in the broader sense of the word) restore a UA feature, and not necessarily something we need to all be the same on? (Feel free to split this into another thread if necessary. :-)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I think there are some serious benefits to saving the<br>
pushState'ed state across sessions. Suppose I'm using a webmail<br>
client which uses this new API. I click around to a few of my folders<br>
and messages and then close the browser.<br>
<br>
If the page wants the back/forward buttons to work when the browser<br>
re-opens, it needs to store all of the state for those history entries<br>
in the URI. At the point that pages have to do that, we might as well<br>
not store a per-page state object.</blockquote><div><br></div><div>Overall, I think preserving history API information when restoring sessions is a good thing. My only concern is whether web developers will program in such a way that this works. Unless ALL state will need to be either saved in the history API or reconstructible from that information, bad things will happen. (Note that this was difficult if not impossible with the original API, but your new proposal makes this quite practical.)</div>
<div><br></div><div>Do most web apps that use iframe hacks (for tracking history) come back cleanly from a session restore?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> I still think we shouldn't force app developers to serialize everything to<br>
> strings. Maybe we can just raise an exception if they try to set the<br>
> history state to something unserializable? (I guess that's what you're<br>
> already doing?)<br>
<br>
</div>Right now, I just serialize to JSON and throw an exception if that<br>
fails. I don't have a problem continuing to do that, at least until<br>
we get the structured clone thing sorted out.</blockquote><div><br></div><div>Yeah. I think the structured clone semantics are the right way to go here (but JSON is a good first approximation).</div></div>