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)
Tracking
()
VERIFIED
FIXED
M14
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.
Updated•25 years ago
|
Assignee: warren → don
Comment 1•25 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•25 years ago
|
Target Milestone: M12
Comment 2•25 years ago
|
||
Hey Don, Someone's going to fix this for m11/12/13, right?
Bulk move of all Necko (to be deleted component) bugs to new Networking
component.
Comment 6•25 years ago
|
||
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•25 years ago
|
Assignee: radha → pollmann
Component: Networking → HTML Form Controls
Comment 7•25 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•25 years ago
|
||
Tried today 2000.01.17.08, and text input, checkboxes get lost again when going
back.
Updated•25 years ago
|
QA Contact: paulmac → ckritzer
Comment 9•25 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•25 years ago
|
||
I agree with akkana, this is really annoying.
Comment 11•25 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•25 years ago
|
||
Putting on PDT+ radar for dogfood.
Whiteboard: [PDT+]
Target Milestone: M15 → M14
Comment 13•25 years ago
|
||
*** Bug 25922 has been marked as a duplicate of this bug. ***
Comment 14•25 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).
Comment 15•25 years ago
|
||
*** Bug 26170 has been marked as a duplicate of this bug. ***
Comment 16•25 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•25 years ago
|
||
Nisheeth, can you make sure listboxes work after your fix? If not, feel free to
poke me about it. :)
Assignee | ||
Comment 18•25 years ago
|
||
Hyatt is the one who completely understands this one. Passing this on to him...
Assignee: nisheeth → hyatt
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 19•25 years ago
|
||
*** Bug 27127 has been marked as a duplicate of this bug. ***
Comment 20•25 years ago
|
||
Is this related to bug 17685?
Comment 21•25 years ago
|
||
No, bug 17685 is a separate issue.
Comment 22•25 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•25 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•25 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•25 years ago
|
Whiteboard: [PDT+] → [PDT+] No estimated fix date. Problem still unknown.
Comment 25•25 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•25 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•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 27•25 years ago
|
||
Accepting bug.
Assignee | ||
Comment 28•25 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•25 years ago
|
Whiteboard: [PDT+] No estimated fix date. Problem still unknown. → [PDT+] Expected Fix Date: 2/14
Assignee | ||
Comment 29•25 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
Closed: 25 years ago
Resolution: --- → FIXED
Comment 30•25 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•25 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•25 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.
Description
•