Forms lose info upon back-button press

VERIFIED FIXED in M14

Status

()

Core
Layout: Form Controls
P3
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: Chris McAfee, Assigned: Nisheeth Ranjan)

Tracking

Trunk
Other
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Assignee: warren → don

Comment 1

19 years ago
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.

Updated

18 years ago
Target Milestone: M12

Comment 2

18 years ago
Hey Don, Someone's going to fix this for m11/12/13, right?

Comment 3

18 years ago
Move to M13.

Comment 4

18 years ago
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Updated

18 years ago
Assignee: don → radha
Target Milestone: M13 → M15

Comment 5

18 years ago
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.

Updated

18 years ago
Assignee: radha → pollmann
Component: Networking → HTML Form Controls

Comment 7

18 years ago
Yes, this sounds like it's probably something awry with the save/restore
routines on the select.  I'll take a look, thanks!

Comment 8

18 years ago
Tried today 2000.01.17.08, and text input, checkboxes get lost again when going
back.

Updated

18 years ago
QA Contact: paulmac → ckritzer

Comment 9

18 years ago
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
(Reporter)

Comment 10

18 years ago
I agree with akkana, this is really annoying.

Comment 11

18 years ago
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

Comment 12

18 years ago
Putting on PDT+ radar for dogfood.
Whiteboard: [PDT+]
Target Milestone: M15 → M14

Comment 13

18 years ago
*** Bug 25922 has been marked as a duplicate of this bug. ***

Comment 14

18 years ago
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).

Updated

18 years ago
Blocks: 22580

Comment 15

18 years ago
*** Bug 26170 has been marked as a duplicate of this bug. ***

Comment 16

18 years ago
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

Comment 17

18 years ago
Nisheeth, can you make sure listboxes work after your fix?  If not, feel free to
poke me about it.  :)
(Assignee)

Comment 18

18 years ago
Hyatt is the one who completely understands this one.  Passing this on to him...
Assignee: nisheeth → hyatt

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 19

18 years ago
*** Bug 27127 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
Is this related to bug 17685?

Comment 21

18 years ago
No, bug 17685 is a separate issue.

Comment 22

18 years ago
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.

Comment 23

18 years ago
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?

Comment 24

18 years ago
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.

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+] No estimated fix date. Problem still unknown.

Comment 25

18 years ago
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. 

Comment 26

18 years ago
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
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 27

18 years ago
Accepting bug.
(Assignee)

Comment 28

18 years ago
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.
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] No estimated fix date. Problem still unknown. → [PDT+] Expected Fix Date: 2/14
(Assignee)

Comment 29

18 years ago
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
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 30

18 years ago
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

Comment 31

18 years ago
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

Comment 32

18 years ago
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.