Closed Bug 35566 Opened 25 years ago Closed 25 years ago

Using Back to return to a form page clears current values

Categories

(Core :: DOM: Navigation, defect, P1)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: cks+mozilla, Assigned: radha)

References

()

Details

(Keywords: regression, Whiteboard: [nsbeta2+][dogfood-])

Build ID: 2000041109 If you fill in a form with a bunch of values, then submit the form, and then use Back to return to the form's page, you return back to a page where all of your filled-in values have been lost: the form has reverted to its default settings. Reproduction: - go to Bugzilla's query page. - fill in or change a bunch of options. - submit query. - Back up to change the options you filled in slightly. - oops! you're back to square one. This bug certainly makes it hard to use Mozilla to search its own bug pages before making bug submissions...
That's part of bug #35448 "autosave to forms (slightly different from wallet feature)". But that bug calls for a different feature when a submit was successful: > Once it is actually sent (assuming there are no errors in the cgi server > script), I won't need the contents that I have written anymore so what I have > written could be auomaticly deleted.
I disagree. Bug #35448 seems to be more of an enhancement request (save the data one is typing into something against a browser crash). This bug is more that Mozilla is either reloading the form off the network when it shouldn't be or resetting the form values when it redisplays it. I consider this a real bug (certainly it's a usability hit, and different from how Netscape 4.72 does it). I don't think any other browser saves in-progress form submissions and stuff the way bug #35448 would like it to be.
updating component and owner. Maybe this is really History? not sure.
Assignee: asadotzler → rods
Status: UNCONFIRMED → NEW
Component: Browser-General → Form Submission
Ever confirmed: true
QA Contact: jelwell → ckritzer
Eric, I am not sure whether this is yours or not.
Assignee: rods → pollmann
I just set a breakpoint in nsComboboxControlFrame::SaveState and ::RestoreState. Neither was called in this case (as both should have been). That points to possibly a general session history bug. Radha, can you take a look? Thanks!
Assignee: pollmann → radha
Component: Form Submission → History
Just tested, this bug is present on today's NT build too.
OS: Linux → All
Hardware: PC → All
carrying over the cc list from bug 37823 (those who weren't already here) b/c i'm going to close that one as a dupe.
*** Bug 37823 has been marked as a duplicate of this bug. ***
Transferring keywords from bug 37823. This is a serious dogfood issue when trying to use bugzilla: spend time composing a detailed bug report, forget to fill out the component, hit submit, and your details are lost forever. It's also a regression.
Severity: normal → major
Status: NEW → ASSIGNED
Putting on [nsbeta2+][dogfood-] radar. Does not need a fix ASAP for daily work, but we should fix this for beta2.
Whiteboard: [nsbeta2+][dogfood-]
PresShell::CaptureHistoryState() doesn't seem to be getting called at the correct time to save the form frame state. We do attempt to restore the state OK, but we never save it when leaving the page.
I see that in the new docshell world, the nsILayoutHistoryState code is not hooked up. This s'd be fixed when it is done. Travis was suppose to do this. But, now I'll be able to get to this only next week.
Priority: P3 → P1
Target Milestone: --- → M16
Blocks: 16806
Depends on: 39667
*** Bug 40156 has been marked as a duplicate of this bug. ***
*** Bug 40515 has been marked as a duplicate of this bug. ***
Move to M18.
Target Milestone: M16 → M18
Fix in hand. Shall checkin once tree opens
Target Milestone: M18 → M16
I don't know if this is the same problem or not but using Windows Build 2000053108 on NT4.0 SP 6 a slightly more sever version of the back page error can be produced as follows: Fire up Mozilla to www.mozilla.org Type url www.mudconnector.com Press search button on left of screen. Enter search term 'godwars' works well. Select any item from the list of hits. Back page. Hey presto back at www.mozilla.org This is constantly repeatable. Sorry if this is just repeating what has already been mentioned above.
That last problem is a bug in session history, and should be filed separately.
the problem described by Robert.Thorneycroft@BrakeBros.co.uk is not related to form elements clearing upon back/forward. It is related to frameset page not working properly with SH. There are bugs filed for it. THis has been fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
not sure what the heck happened to the resolution on this (good ol' bugzilla...), but reopening
Status: RESOLVED → REOPENED
...and fixed...
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Marking VERIFED FIXED on: - MacOS9 2000-06-01-20-M16 Commercial Build - Linux6 2000-06-01-20-M16 Commercial Build - Win98 2000-06-01-21-M16 Commercial Build
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: ckritzer → docshell
You need to log in before you can comment on or make changes to this bug.