[whatwg] Proposed changes to the History API

[Mike Wilson]

Justin Lebar wrote:
> Mike Wilson wrote:
> > 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.)
> 
> STR:
>   * Open 
> https://bugzilla.mozilla.org/attachment.cgi?id=386244&action=edit
>   * Click "Edit as comment"
>   * Change the text in the textarea
>   * Close and re-open your browser
> 
> Actual behavior: The textarea is back to its original state, read-only
> and without your edits.  Even after you press "edit as comment", the
> state still doesn't reflect the changes you made before you closed the
> browser.

Hm, it seems you didn't get my point. I was referring to
your statement saying that it wasn't possible for the form 
field value persistence to do its job because the textarea
was created and populated onload. I was pointing out that
this is not the case, as the textarea and its content
are indeed delivered in the "static" HTML right from the
server and not created onload. 
Thus, this textarea is fully functional with the browser's 
form field value persistence mechanism, as can be seen if 
you revisit the textarea within the same browser session.

I understand that persistence between browser restarts is
one of your goals, but I have never said that the current
incarnation of form field value persistence persists 
between browser restarts. Or are you saying that?
Indeed, if Mozilla's implementation did that, I would 
expect it to work straight off with the discussed bugzilla
page, due to its simple and form-friendly design.

Best regards
Mike