<div class="gmail_quote">On Fri, Aug 21, 2009 at 12:26 PM, Mike Wilson <span dir="ltr"><<a href="mailto:mikewse@hotmail.com">mikewse@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Justin Lebar wrote:<br>
<div class="im">> Mike Wilson wrote:<br>
> > Sorry, it seems we are not talking about the same application.<br>
> > Jonas referred to attachment pages in your bug database, which<br>
> > I assumed would f ex be a page like this one:<br>
> > <a href="https://bugzilla.mozilla.org/attachment.cgi?id=386244&action=edit" target="_blank">https://bugzilla.mozilla.org/attachment.cgi?id=386244&action=edit</a><br>
> > (The textarea in this app is not created onload, it is delivered<br>
> > in the server-generated HTML and thus is subject to form field<br>
> > value persistence.)<br>
><br>
> STR:<br>
> * Open<br>
> <a href="https://bugzilla.mozilla.org/attachment.cgi?id=386244&action=edit" target="_blank">https://bugzilla.mozilla.org/attachment.cgi?id=386244&action=edit</a><br>
> * Click "Edit as comment"<br>
> * Change the text in the textarea<br>
> * Close and re-open your browser<br>
><br>
> Actual behavior: The textarea is back to its original state, read-only<br>
> and without your edits. Even after you press "edit as comment", the<br>
> state still doesn't reflect the changes you made before you closed the<br>
> browser.<br>
<br>
</div>Hm, it seems you didn't get my point. I was referring to<br>
your statement saying that it wasn't possible for the form<br>
field value persistence to do its job because the textarea<br>
was created and populated onload. I was pointing out that<br>
this is not the case, as the textarea and its content<br>
are indeed delivered in the "static" HTML right from the<br>
server and not created onload.<br>
Thus, this textarea is fully functional with the browser's<br>
form field value persistence mechanism, as can be seen if<br>
you revisit the textarea within the same browser session.<br>
<br>
I understand that persistence between browser restarts is<br>
one of your goals, but I have never said that the current<br>
incarnation of form field value persistence persists<br>
between browser restarts. Or are you saying that?<br>
Indeed, if Mozilla's implementation did that, I would<br>
expect it to work straight off with the discussed bugzilla<br>
page, due to its simple and form-friendly design.</blockquote><div><br></div><div>I think whether or not a particular UA persists form field data (or anything other than history API data) is completely orthogonal to this discussion. For the sake of this discussion, lets assume there's some UA out there that ONLY persists history API data for recovery. That way the history API doesn't depend on any of these other features. Agreed?</div>
<div><br></div><div>Getting back to your question, with both the original and the newly proposed API this is possible. The difference is that with the newer API, it's much easier to update an entry. For example, if I wanted history to include what was typed into a particular form field, I could just keep updating the history entry whenever the text changes or when I add a new history entry. With the old API, I'd have to create a unique ID that gets pushed via the history API, and then maintain all of that state elsewhere. I then depend on either both or neither of those APIs surviving a recovery.</div>
<div><br></div><div>This is one of the reasons I think the proposed changes to the API are much more usable.</div><div><br></div><div>J</div></div>