[whatwg] Proposed changes to the History API

Justin Lebar wrote:
> The pushState function as currently specified allows you to do
> precisely this.  History.pushState(obj, title, url) creates a new
> history entry with the given URL, but doesn't load a new document.

Ah thanks, I had missed the part saying that path and query
were ok to change. I think this part of the spec is very
controversial though, but I'll spawn that discussion to
another thread.

> >> ?It would further be nice if your comments weren't lost even if you
> >> navigate away from the page.
> >
> > This is the way it works in most browsers, as the browser persists
> > form field values when you navigate back and forth in history.
> 
> Right.  But the difficulty with this page in particular is that it's
> structured such that it's difficult/impossible for the browser to
> properly restore its form state after a crash.  Onload, the page
> creates a <textarea> and populates it with the text of the patch.  So
> if we crash then restore, the page won't have created the textarea by
> the time the browser looks to restore the text.

Sorry, it seems we are not talking about the same application.
Jonas referred to attachment pages in your bug database, which
I assumed would f ex be a page like this one:
https://bugzilla.mozilla.org/attachment.cgi?id=386244&action=edit
(The textarea in this app is not created onload, it is delivered
in the server-generated HTML and thus is subject to form field
value persistence.)

What app are you talking about?

> what we really want is a
> way to programmatically do the restore.

Certainly, that's why we are all here I guess :-)
Being able to do similar things as form field value persistence
and scroll position persistence, but for your own data, is the
purpose of history states, IMO.

Best regards
Mike

Received on Friday, 21 August 2009 00:56:29 UTC