158258 - HTTP form POST data is lost on (accidental) close, quit or crash

Status: RESOLVED DUPLICATE of bug 328154

(Core :: Layout: Form Controls, defect, P2)

Description

[Lars Aronsson]

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.

Comment 1

[Patrick Xia]

-> 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. 

Comment 2

[Lars Aronsson]

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. 

Comment 3

[Lars Aronsson]

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.

Comment 4

[Patrick Xia]

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..

Comment 5

[Alexandru Savulov]

Attachment: testcase

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.

Comment 6

[Alexandru Savulov]

Attachment: new testcase

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.

Comment 7

[Alexandru Savulov]

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

Comment 8

[Lars Aronsson]

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.

Comment 9

[Alexandru Savulov]

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.

Comment 10

[John Keiser (jkeiser)]

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.

Comment 11

[Lars Aronsson]

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.

Comment 12

[Brad K.]

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'.

Comment 13

[Vladimir Ermakov]

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.

Comment 14

[Vladimir Ermakov]

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.

Comment 15

[Vladimir Ermakov]

->

Comment 16

[Brant Gurganus]

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.

Comment 17

[Andrew Hagen]

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

Comment 18

[Jo Hermans]

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

Comment 19

[:Gavin Sharp [email: [e-mail]]]

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