- From: Mike Wilson <mikewse@hotmail.com>
- Date: Fri, 21 Aug 2009 21:26:36 +0200
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
Received on Friday, 21 August 2009 12:26:36 UTC