[whatwg] Proposed changes to the History API

[Mike Wilson]

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