User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 Form field data should be retained after session restore. Reproducible: Always Steps to Reproduce: 1.Start Firefox 2.Load this test form http://bclary.com/projects/form-utils/form.pl?method=post 3.Make note of the counter and time 4.Modify some of the input fields 5.Kill Firefox 6.Start Firefox and if you see the Restore Session error page, restore your session 7.Submit the form 8.Kill Firefox again and restart it 9.If you see the Restore Session error page, restore your session Actual Results: 1.Both times I restore the session the form field is not changed, counter and timer should are not restored to the same values as before you killed Firefox, they are restored to default values. 2.The form field data are the default ones, not the ones entered at step 7. Expected Results: 1.Both times you restore your session the form field changes, counter and timer should be restored to the same values as before you killed Firefox 2.The form field data should not reflect the defaults, it should be the data entered at step 7. 3.You should not see the Restore Session error page the first time you kill Firefox.
This issue is a regression of Bug 346337.
Depends on: 346337
(In reply to comment #1) > This issue is a regression of Bug 346337. Sort of. That bug added the capability of tracking many more types of input. The actual issue here is that we no longer save values for form fields that still have the default value after bug 537289. That test page you use sets the value of each input after you submit it. So when the page is loaded after submitting, the values in the fields are set by the server, not (explicitly) by the user. I'm ok taking this as a regression for now with the performance improvements we get in exchange.
I know it's off topic and I apologize for this... but I was wondering if the behaviour of Firefox can be reverted as it was before Bug 537289 by changing any setting, or using a workaround... I can't go on like this, every time I save my tabs or Firefox/Windows crashes I lose everything I was writing on Wikipedia, and I have to start all over again!
I'm not a developer - but I'd like to suggest a fix that could be a good compromise between the speed benefits we had from Bug 346337 and the need to lose not field values in the cases reported in the current bug and in Bug 648845. The idea is that Firefox saves form field values only if they are different from the default ones (just like now), except when the site domain is included in a sort of whitelist: in that case field values are always saved. The whitelist should include all the websites affected by this problem (or at least the most popular ones). Is it feasible?
(In reply to comment #6) It's feasible, but I don't think it's a change we want product-wide (ie. default behaviour for all users). It would be more appropriate to enable this functionality through via an add-on. Feel free to file a bug for that setting the severity to ENHANCEMENT.
Yes, I think it should be the default behaviour for all users. Any user could (for example) edit a Wikipedia article and lose the changes he made if Firefox crashes or if he closes the browser saving the session when the edit is not saved yet.
(In reply to alessandroantonelli2 from comment #9) > Any news? Paul is unavailable until October 4. You will have to wait until he gets back and goes through his backlog.
I don't think we should have a whitelist functionality here. That's a fair amount of extra code to maintain for little gain. I think there are addons that may better serve what you need.
Maybe save everything for, say, only those pages gotten in response to POST? I think this bug might be why I've been losing so many Wikipedia/etc. edits lately: I probably preview, make no changes, then go off and crash the browser (well, kill it because it's thrashing the swap).
(In reply to Samuel Bronson from comment #12) > Maybe save everything for, say, only those pages gotten in response to POST? This seems like a good suggestion to me, let's do that. We should save form values for pages retrieved by POSTing regardless of whether they have the default value or not.
Hardware: x86 → All
Whiteboard: [4b9] → [triage]
Version: unspecified → Trunk
Hi Teodosia, The link you provided is no longer available, can you please provide another one so I can test this on my end? Thanks.
Marking this as Resolved: Incomplete due to the lack of response from the reporter. If anyone can still reproduce it on latest versions, feel free to reopen the issue and provide more information.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.