Closed Bug 327304 Opened 18 years ago Closed 12 years ago

Going Back clears forms for many sites

Categories

(Firefox :: General, defect)

PowerPC
macOS
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugzilla.mozilla.org, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: dataloss)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060203 Camino/1.0rc1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060203 Camino/1.0rc1

The criteria for Firefox not retaining session history for forms seem to not be tilted enough in the data-retention direction. I've had many instances of filling in a form to submit a comment, clicking a link before hitting submit, and then going back (via Back button) and finding my form cleared. It seems that Firefox is reloading pages instead of using the already-loaded page in much wider circumstances than, for example, Safari. 

Perhaps the criteria for retaining form session history can be expanded. Losing form data just by looking at another page then going back does result in a lot of pain for users who can easily lose large quantities of data.

There are other bugs that mention this, but they don't seem to directly address just how frequently this can occur, nor do they describe what the criteria are for dropping form data. One bug is #303638.

Is there a document that explains this choice, if it truly was a choice to drop data so often?

Reproducible: Sometimes

Steps to Reproduce:
1. Go to a site with a form (example: http://babelfish.altavista.com/)
2. Type in some information.
3. Click a link (or choose a bookmark) to load another page.
4. Go Back.
5. Realize everything you had typed in is gone.
Actual Results:  
Data loss.

Expected Results:  
Data retention.

Now, I understand there are cases where form data should not be retained, but it seems to me that the examples I mentioned are NOT cases where form data should be disposed.
Ah, perhaps this is a dupe of 209292.

Actually, it seems to depend on bug 288462 (I marked the "depends on"). This is really a big issue - as more and more people use web applications to store their data, they will be composing large quantities of text in web forms. Clicking a link then going back should almost never (unless explicitly demanded by the site) wipe out all that information.

There is quite a tangled web of bugs reporting various aspects of this issue, but the form data loss is a significant problem for users. I don't know how to connect all the bugs together, but not losing form data is very important to me (and probably everyone else, too).
Depends on: 288462
Version: unspecified → Trunk
The worst is if the form is filled incorrectly. You then try to go back and fix it and it is all blank again.
AFAIK This happens when the pages is retrieved again, I think due to Pragma: no-cache or just the cache misbehavior described in bug 288462

There may be a dupe out there, but I'm not finding an exact one readily.
Severity: critical → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss
Whiteboard: dupeme
Blocks: 288462
No longer depends on: 288462
Component: History → Bookmarks & History
QA Contact: history → bookmarks
do you still see this problem?
http://babelfish.altavista.com/ WFM FF3
Component: Bookmarks & History → General
QA Contact: bookmarks → general
  Worcester12345   do you see this?  is it a dupe?
I have seen this on Windows as well.
I couldn't reproduce this issue on Windows with Fx 3.6.4. I tried http://babelfish.yahoo.com/ and bugzilla.mozilla forms as well.
(In reply to comment #5)
>   Worcester12345   do you see this?  is it a dupe?

(In reply to comment #6)
> I have seen this on Windows as well.

I think this is working better now. Is this dependent on cookie handling? I know sometimes a newspaper I log in to post comments on, if you go "back", it will be blank, and I lose a lot of typing. I don't know of a definitive way to check this though. The site is http://www.telegram.com

There may be others as well.
I can't reproduce this bug in Firefox 6.
WFM also per reporter
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: dupeme
You need to log in before you can comment on or make changes to this bug.