Applications like webmail (e.g. www.hotmail.com), wiki (e.g. www.wikipedia.com) , or weblogs (e.g. www.slashdot.org) mean that people use HTML POST forms for ever more important tasks, where long texts are written from the web browser. During this long time, the system or network might crash, or the user might hit Close or Quit by mistake, meaning that all work is lost. This is true in Mozilla 1.1alpha, and all earlier versions back to the first NCSA Mosaic. Applications such as word processors (e.g. MS Word) or text editors (e.g. Emacs) have perform a regular autosave to safeguard against this. Several text mode mail readers (e.g. Pine) save a canceled letter in ~/dead.letter from where the abandoned text can be rescued. Mozilla needs a feature like this. When the browser is closed or quited and there is unsaved/unsubmitted or unsuccessfully submitted POST data (the server's response indicated an error or timeout), the data should be saved and the user should be asked if she really wants to abandon the text. (Actually, the save to local disk should be done continuously during the edit, to safeguard against a browser crash.) On the next browser start, the user should be prompted with the option to continue working on the saved form data.

-> Browser / Form Submission -> NEW Additional comments: I say this, if this is to be implemented, should be a option in preferences, maybe a checkbox. Sometimes, quitting out of a form is intentional, and usually, I don't want another box asking me if I want to abandon data.

On the other hand, too many preference options is also bad. Perhaps the behavior could be made to depend on the amount of work (time spent or bytes entered) that would be lost by abandoning the form. If a dialog pops up, it could have a "never ask this again" checkbox, to minimize noise.

It happened again today. I was editing a really nice text, and moved the cursor back and forth with the arrow keys. Then my left thumb hits the alt key as my right thumb hits the left arrow key. Suddenly, my browser moves back to the previous page, and when I move forward again to the HTML form, my entire text is gone, gone, gone. Nowhere to be found. I *HATE* when this happens. I *HATE* this browser that does this to me. It is Mozilla 1.1alpha. It is the line eater of the 21st century, it is the dragon eating tree, it is the text eating browser.

While this bug is being fixed (hopefully; it's in NEW status, shift it to ASSI?): you can utilize the following work-around: write stuff in your text-editor, then copy and paste..

this is the testcase reduced from the mail composing page on hotmail. as you can see there is a table interlaced with a form element. that is bad html. still i think that we should do something about that.

sorry, i pointed to the wrong problem. this test case contains the real problem. there is a form wrapped by a table, the form has an input that is not contained in any row of the table and an input that is contained in a table row.

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

As Scott Gifford has pointed out in Bug 140697 Comment #12, that bug is very different from this one. The bug that I posted (this one) is not about illformed HTML, but about the browser's need to behave like a text editor.

John, i cannot get to this soon. It is a "nice to have" feature. We would be the first ones to have it i guess, so go for it dude! :-) Here is my 2 cent idea: have a text (dat) file created at some point when the user inserted more than a line of text(just a suggestion), the file has the action URL as filename(or part of the name) and is updated every time the user inputs 10 words (or comes to a new line, whatever). so, even a crash would prevent the whole data to get lost. when the user browses again the url, if there is the form, the form control will look for the latest file that has the URL and ask the user if he wants to restore the data. after a successful submission, delete the file.

Losing data on quit / close is bug 48333, we will pop up a dialog when you have entered a significant amount of data. On crash, though ... There is almost no way a save/restore feature could work. The best I can think of is to create a bookmark or bookmark group that contained the entered data and the URL you were at when you entered it. Still, the page can (and in the case of Hotmail, *will*) be different when you go back to it later, which renders this feature useless. In the case of Hotmail going back to the compose window URL, Hotmail will bring up a login page instead of a compose page, rendering the saved data useless.

John, in comment #10 you write about bookmarks and conclude "there is almost no way a save/restore feature could work". I think you should approach the problem from a different angle. When I edit a long text and the browser crashes (or I make it crash by accident), I will return to that text pretty soon. Maintaining the last one, two or perhaps three lost documents will be sufficient, and the bookmark or URL is less important. Autosaving the long text in a plain file "~/dead.letter" (or ~/.mozilla/dead.form) would do fine. That file might contain a header (XML tags or RFC822 style) that indicates the URL and form field names, but that is not critical (i.e. the URL is an attribute, not a primary key). The problem that the function should solve is to reduce the frustration of losing the long text.

Just a thought -- The Password Manager detects logins and saves passwords. Could form data be detected, and saved to a 'restore' function which is cleared when the 'Submit' button is clicked, or the user performs a successful exit-on-request? Or maybe retain for a selectable history period (default 2 days) or 'submit'.

We have a feature called Form Manager, that does just that. You can save the data from a form and then restore it in case the window got closed. To use it go to Tools/Form Manager/Save Form Info, and then you can use Tools/Form Manager/Fill in Form to fill out the form again. If you find bugs/feature requests/sites that it doesnt work on report them under Form Manager component.

I asked Steve Morse about this, and he said that the Form Manager is not designed to save data from text areas. As I understand it is not site based, and is mostly for filling out frequently requested data like name or zip code... Moving this to Form Controls, because that seems a more appropriate area for this request.

->

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

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

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

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