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
