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)
Core
DOM: Navigation
Tracking
()
VERIFIED
FIXED
M16
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...
Comment 1•25 years ago
|
||
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.
Reporter | ||
Comment 2•25 years ago
|
||
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.
Comment 3•25 years ago
|
||
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
Comment 5•25 years ago
|
||
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
Comment 6•25 years ago
|
||
Just tested, this bug is present on today's NT build too.
OS: Linux → All
Hardware: PC → All
Comment 7•25 years ago
|
||
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.
Comment 9•25 years ago
|
||
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
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 10•25 years ago
|
||
Putting on [nsbeta2+][dogfood-] radar. Does not need a fix ASAP for daily work,
but we should fix this for beta2.
Whiteboard: [nsbeta2+][dogfood-]
Comment 11•25 years ago
|
||
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.
Assignee | ||
Comment 12•25 years ago
|
||
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
Comment 13•25 years ago
|
||
*** Bug 40156 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
*** Bug 40515 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 16•25 years ago
|
||
Fix in hand. Shall checkin once tree opens
Target Milestone: M18 → M16
Comment 17•25 years ago
|
||
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.
Comment 18•25 years ago
|
||
That last problem is a bug in session history, and should be filed separately.
Assignee | ||
Comment 19•25 years ago
|
||
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
Comment 20•25 years ago
|
||
not sure what the heck happened to the resolution on this (good ol'
bugzilla...), but reopening
Status: RESOLVED → REOPENED
Comment 21•25 years ago
|
||
...and fixed...
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 22•25 years ago
|
||
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.
Description
•