In any form, clicking reload, or going to web page accidentally and going "back" to that web page will render all user input into that form non-existent. That contradicts a fundamental rule of human-interface design: if the user types it in, it has value. The longer the user is doing it, the more value it has - some non-volatile system of form input persistence would be worthy of consideration ... "later". Fixing the immediate problem of loss of data at a single keystroke is of pivotal import. Form data should never be wiped at a whim - hitting ctrl-r (which happens to be next to ctrl-t for tabs) should not destroy an hours worth of email. Yet it seems to. This bug is the source of *enormous* frustration for me. You cannot imagine how difficult it was to write this bug report without cursing and swearing. :/

Which build are you using ? I tried reloading a page (this one), and the text I typed wasn't lost after a reload !

humm, I thought this worked quite well for me. until I just tested it, aggressively. It's either intermittent or form data is lost on a page with frames Only. build: 20020327, win95. test site: http://www.mrc-gprf.ac.uk/contact_frameset.html

Confirmed on v0.9.9+ build 2002032708 win98 on test page with frames as in comment #2

Using build 2002032708. Yes, the data loss on reload (or new-page + 'back'), as I encountered it, was inside a frameset. Impressive job in figuring that out. :) This occurs on Linux and Windows alike, so I am flagging OS: All

marking new. this directly clashes with bug 46845 [clear form upon page refresh].

In order to avoid a religion war, I'd say that a plain reload would keep the text in the forms, while a SHIFT+reload (that normally would reload the whole page ignoring the cache) would regenerate a fresh page with all the fields empty.

************************* frameset vs. single frame ************************* ok, looks like there is a problem on frameset pages. if the above URL is loaded, you type in the form fields and hit CTRL+R the fileds get wipped out. but if you rightclick the form frame and chose "show only this frame", then you do the same, the content is not removed. i tried that even with pages that have initial values set and is still working, the typped value are not forgotten. we must fix this for framesets. anyone that saw this on non-frameset pages please tell us which build/os/URL.

The refresh/reload issue is simple enough: user types in data, and erases it unwittingly with a single keystroke. That's fundamentally wrong, a source of frustration, and a design flaw. An application should have state of at least a single depth to return to. Second, an issue not addressed herein is the clicking on a link, presumably accidentally, then hitting the back button, yields an empty field. That is similarly fundamentally wrong, and a poor design choice. (Not sure if mozilla is designed with that in mind.) Third, I can reproduce the refresh issue on a non-frameset in Mozilla with the squirrel mail compose window (by opening the link from a frame in a new tab -- does that change the state of the frame to be equivalent to frameless?). I have conjured up this problem on the intranet, but the best I can offer for reproduction is the location of squirrel mail: http://www.squirrelmail.org/. This might be mitigated by the opening of the link in a new tab/window, however. Fourth, to the average user, this would be a source of insurmountable frustration. It has personally cost me $240 in lost hours, in the past 24 hours, due to hitting C-r instead of C-t and accidentally tapping the touchpad so it went to a link and lost all my data since the "back" button didn't retain. So, by design or otherwise, the easy (ie one key or one mouse click) loss of data threatens the "safety" of the data I type into the browser.

i checked the following URL: http://www.squirrelmail.org/feedback_form.php the response header from server contains: Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache i tried to emulate the same with my test server (setting the same header fields) and i couldn't reproduce (although I use the same server/PHP versions as sourceforge). testing...

ok, with the original page from my server I was able to reproduce. ******************** TEST WITH THIS URLs: ******************** - on a normal page http://www.squirrelmail.org/feedback_form.php - on a frameset page http://www.mrc-gprf.ac.uk/contact_frameset.html

ok, here are the results: on the URL http://www.squirrelmail.org/feedback_form.php the Cache-Control: no-store flag in the server's response header causes the content to be deleted and is NOT A BUG. (see HTTP 1.1 - RFC 2616 / sec. 14.9.2) the only issue remaining here is visible on the URL http://www.mrc-gprf.ac.uk/contact_frameset.html and is a frameset problem. Reassigning to Jkeiser since he's the state recovery agent ;-)

------- Additional Comment #11 From Alexandru Savulov 2002-03-29 11:01 ------- ... the Cache-Control: no-store flag in the server's response header causes the content to be deleted and is NOT A BUG. (see HTTP 1.1 - RFC 2616 / sec. 14.9.2) ... It is reasonable to believe, given that I have been driven to rage enough times to post here, that many users will be frustrated beyond reason by hitting ctrl-R to refresh a page and have Mozilla destroy hours of work without a hesitation. The words "Destroy" and "work" highlighting the most operative consequences of not addressing this, albeit minor in most cases now, issue. :) A confirmation that the user will lose all their form data when they hit c-r would be a sufficient fix, allowing Mozilla to remain standards compliant, and nevertheless stave off ignoring fundamentals of human interface design and the impotent wrath of bitter and cynical computer users such as me. Plus, it should be a relatively trivial fix to ask "This page requires that you will lose everything you just typed in to refresh" prior to refreshing. The frameset issue is a different beast altogether.

reporter: please file a new bug to User Interface Design for the message box improvement. they have to decide if the feature is implementable or not since the events fired by c-r and mouse-click are the same from the perspective of form submission. thanks!

Of course this if "fixed" just further destroys javascript in forms and perpetuates the dataloss problems talked about in bug 46845 But I guess Mozilla should be consistent in making sure javascript isn't used in forms at all. Then again reseting hidden form fields and not reseting visible ones is inconsistent in the first place, and setting your cache to retrieve a page every time, really doesn't do that. So consistency really doesn't matter apparently.

I am frustrated by this bug, too, but *not* on a framed page! It notice it the most on www.livejournal.com while writing comments. When I press the 'Preview' button instead of Submit, I get shown the preview of the comment. To correct any mistakes, I have to use the Back-Button and presto.. the comment is gone. I can still go forward again, grab the text, go back and insert it again, but this is damn frustrating (and HTML tags loss nags, too). To test this, you can do the following: - visit any journal on www.livejournal.com - click on the comment link on an entry - write some comment text - press Preview button - go back a page

I'm not able to reproduce the case where hitting Back loses the contents of text fields (neither on frameset nor on non-frameset pages). Can anyone provide an URL and some steps to reproduce, please?

(sorry for accidentally changing the summary.) There are two issues described here: One is about form fields getting cleared when you press Reload, the other is about form fields getting cleared when you go to another page and press Back. Those are two separate bugs (though I would argue that the first is invalid) and should not be in the same bug report. The first issue mentioned in this report is the one about pressing Reload. If you are still experiencing the other bug, please file a separate bug report about that.

If both are happening, then they are the same bug. We generally treat reload and back the same way, and any fix would fix both.

> We generally treat reload and back the same way, and any fix would fix both. But the one about reload isn't a valid bug. Reload is *supposed* to clear form fields -- the fact that it very often doesn't do it is bug 46845. The one about going back, OTOH, is a valid bug which should be fixed.

Wow, I didn't realize that. I have been abusing that feature for a while now on Bugzilla pages, reloading to get the new comments before I submit.

> I have been abusing that feature for a while now on > Bugzilla pages, reloading to get the new comments before I submit. That can be very handy, true, but if someone made changes to the bug (other than just adding a comment), you will overwrite their changes when you submit, without getting a mid-air. And this is just Bugzilla -- imagine the amount of critical dataloss this could cause in other applications. That's why form elements *must* be cleared on reload. (I'm not implying that *you* don't understand this; just trying to make the point to the people who wants bug 46845 to be wontfix'ed.)

*** Bug 138895 has been marked as a duplicate of this bug. ***

Let's keep the Reload discussion out of this bug. We will do for frames whatever we do for normal documents, if we fix this bug.

Google normally restores form controls on reload / forward / back. When it's in a frameset (as it is here) it is not.

I find this to be exceptionally annoying in the case where the user selects 'View only this frame' and suddenly all form data in that frame is destroyed. If frames are interpreted as presenting content, simply changing the size of the frame (or removing adjacent frames) should not change the content within the given frame. I don't know what actions mozilla takes internally when showing only a single frame, but it appears to at least to reload on the page. Is it acceptable to just redraw the content, so the only thing changed is the size of the frame? I should think it would be because that is the case when the user resizes the browser window itself--imagine how perturbed you would be if everytime you resized your browser window the current page was reloaded and all your form data was lost.

Bulk moving P1-P5 un-milestoned bugs to future.

*** Bug 163477 has been marked as a duplicate of this bug. ***

John - I can't reproduce your testcase on 2003041009 WinXP using the Back button (though I agree it reproduces on reload - but this may not be a bug as mentioned above). The form-wipe-on-back-button bug only reproduces when you click on a link which has target="_top", as in the following test case: http://www.sgaclan.com/moz133946/frameone.html In the above form, type some text in the Test Text field, click the "Click Me" link, then click Back. The form is wiped.

By Jove... this bug seems to be fixed in Gecko 20040120 (Firebird 0.7+), at least with the testcase I included above. I can, at last, switch to Firebird :D

Hmm... so back/forward work now, as far as I can tell. At a guess, reloading wipes out the child frames completely and rebuilds them, so they have new docshells and the session history state is not applied to them....

bz: That's interesting, as per bug 46845, reloading shouldn't remember form fields. Of course, the whole dataloss argument in bug 46845 is due to the fact that visible form fields are remembered on reload, while hidden form fields get the new value from the server. Come to think about it, this seems awfully wrong. Would it be an idea to make hidden and visible form fields behave the same on reload? That would fix the corrupted-data-being-submitted, bugzilla-midairs-don't-work dataloss bug, actually regardless of whether form fields are restored or not, as long as hidden and visible fields are treated the same. What do you think?

Please, let's keep the bug 46845 discussion in bug 46845.

*** Bug 293024 has been marked as a duplicate of this bug. ***

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050505 Firefox/1.0+ Form contents are wiped on pages *without* framesets.

Still occurs on Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20140610 Firefox/24.0 Iceweasel/24.6.0, e.g. in SourceForge bug reports: when I post a comment, SourceForce sometimes complains that I'm already logged in (!!!), so that I need to go back, but my comment is lost!