Closed Bug 13537 Opened 25 years ago Closed 25 years ago

Forms lose info upon back-button press

Categories

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

Other
Other
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mcafee, Assigned: nisheeth_mozilla)

References

Details

(Whiteboard: [PDT+] Expected Fix Date: 2/14)

apprunner, linux. Bugzilla, pretend to file a new bug. Type in some long comment :-) forget to pick a component. You get a warning, hit back, poof! all the form information is gone. 4.5 retains the form information for me. This is really annoying! This is not a blocker but would be good to fix.
Assignee: warren → don
I heard that someone was working on saving form data, but it's not a necko thing. I think it's xpapps. Sending this to Don.
Target Milestone: M12
Hey Don, Someone's going to fix this for m11/12/13, right?
Move to M13.
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Assignee: don → radha
Target Milestone: M13 → M15
Radha, isn't most of this fixed now?
I tried just now and the text fields/text areas maintain their content. But I noticed that list boxes (which used to maitain their selections too) don't work right anymore. cc'ing pollmann,nisheeth to check if something regressed.
Assignee: radha → pollmann
Component: Networking → HTML Form Controls
Yes, this sounds like it's probably something awry with the save/restore routines on the select. I'll take a look, thanks!
Tried today 2000.01.17.08, and text input, checkboxes get lost again when going back.
QA Contact: paulmac → ckritzer
Nominating for dogfood: I've been increasingly shying away from using mozilla for bug managing because I've lost quite a bit of time in the last few days due to painstakingly adding bugzilla comments then losing them because of some silly error like forgetting a Component in a new bug, or clicking a url in mail. Of course, there's a workaround: be perfect and don't ever make mistakes. :-)
Summary: Forms lose info upon back-button press → [DOGFOOD] Forms lose info upon back-button press
I agree with akkana, this is really annoying.
Just read jar's note on the new way to designate dogfood/pdt bugs; moving dogfood to keywords instead of summary.
Keywords: dogfood
Summary: [DOGFOOD] Forms lose info upon back-button press → Forms lose info upon back-button press
Putting on PDT+ radar for dogfood.
Whiteboard: [PDT+]
Target Milestone: M15 → M14
*** Bug 25922 has been marked as a duplicate of this bug. ***
Nisheeth, can you take a look, looks like it might be in your area (the SaveState and RestoreState methods are never called on stateful frames).
Blocks: 22580
*** Bug 26170 has been marked as a duplicate of this bug. ***
After taking a look at this, Nisheeth had a moment of nirvana and understands the problem and it's fix completely. He kindly offered to take over the bug. Thanks Nisheeth!
Assignee: pollmann → nisheeth
Nisheeth, can you make sure listboxes work after your fix? If not, feel free to poke me about it. :)
Hyatt is the one who completely understands this one. Passing this on to him...
Assignee: nisheeth → hyatt
Status: NEW → ASSIGNED
*** Bug 27127 has been marked as a duplicate of this bug. ***
Is this related to bug 17685?
No, bug 17685 is a separate issue.
A cursory (non-thorough) examination seems to indicate that we're leaking frames. In particular, I think we're leaking tables. Looking at the bloat/leak data, it looks like all BasicTableLayoutStrategies leak, and it looks like the only way they'd leak is if a table frame didn't get destroyed. If the table frame never gets deleted, then it might be the case that the child frames don't get deleted and never save their state as a result. I'm never seeing anyone save their state when a document gets blown away. Adding troy and karnaze to cc list.
CC'ing Nisheeth, as he might have a different take on this. :) I remember something about mState getting set too soon, and us skipping storing state when exiting a page because of that. Is this related?
I could be totally wrong. I did watch the creation of history states and such, and it looks like everybody has the right one (the frame constructor and the pres shell). It looked like state simply wasn't being saved when you left the page behind. I put breaks all over the CaptureFrameState methods in nsCSSFrameConstructor, and the form controls just weren't getting their frame states captured.
Whiteboard: [PDT+] → [PDT+] No estimated fix date. Problem still unknown.
Hmmm. I find it hard to believe we'd be leaking frames, since the leaks would be a lot worse... I'll look into this more tomorrow after I actually get a full night's sleep for once. I need to stop looking at this bug while totally punchy.
Nisheeth, I am giving this back to you. Following my initial merging of the two history states (session and CSSFrameConstructor) session history worked fine (modulo bugs in specific frames that Rod has since fixed). So some other checkin has to be responsible for regressing it. I tested session history thoroughly prior to my checkin, and it worked, so this bug is something different.
Assignee: hyatt → nisheeth
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Accepting bug.
I have a fix for this in my tree. This was indirectly related to your changes, Hyatt, but probably did not show up when you tested. The problem was that the nsPresShel::GetHistoryState() used to capture frame state all the time earlier and you changed it to capture state only for the case when a new history state is created. I'll check in the fix once the tree opens.
Whiteboard: [PDT+] No estimated fix date. Problem still unknown. → [PDT+] Expected Fix Date: 2/14
I just checked in the fix. Selects still don't save and restore their state. This is a problem with the select frame's save and restore methods, not in the general capture and restore mechanism. Rod Spears has an open PDT+ bug (21945) and a fix in his tree for that issue. Marking this bug resolved.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Marking VERIFIED FIXED on: - Linux6 2000-02-16-16 Commercial build - MacOS9 2000-02-16-16 Mozilla build - Win98 2000-02-16-16 Commercial build
Status: RESOLVED → VERIFIED
Marking VERIFIED FIXED on: - Linux6 2000-02-17-15 Commercial build - MacOS9 2000-02-17-15 Commercial build - Win98 2000-02-17-15 Mozilla build
In case anyone is following the saga, this has regressed again. I couldn't find this bug, so I filed a new one: 37827.
You need to log in before you can comment on or make changes to this bug.