Closed Bug 41555 Opened 24 years ago Closed 22 years ago

Forms do not remember the data when go back on some pgs[form sub]

Categories

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

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.0.1

People

(Reporter: don, Assigned: alexsavulov)

References

(
URL
)

Details

(Keywords: dataloss, Whiteboard: [nsbeta3-][nsbeta1+])

Attachments

(2 files)

proposed fix (one-liner :) )
961 bytes, patch
Details | Diff | Splinter Review
Test case that demonstrates data lossage when refresh pressed.
1.16 KB, application/octet-stream
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.3.99-pre3 i686; en-US; m16) Gecko/20000604
BuildID:    2000060420

After entering info in a form and proceeding to next page, then pressing the
back button to return to the form, the entered info is gone.  This is a very
serious problem as most forum web sites use back button to make corrections.


Reproducible: Always
Steps to Reproduce:
1.Go to above URL
2.Fill in subject and text
3.Select preview checkbox
4.Press "add topic" button
5.Press mozilla's back button
6.Notice what you entered is gone


Actual Results:  what you entered is gone



Expected Results:  text you entered should still be there


One might assume it's because the back button doesn't get the info from the
cache, but I believe there is more to it than that.
This works correctly in ns4.
This is a major problem, so it should be fixed in M16, or this browser wil still
be unusable.
I'm able to reproduce this bug on Mozilla 2000060208 on a PowerMac G3 running Mac 
OS 8.6. Set Platform/OS to ALL and changed summary.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: back button does not function properly → Forms do not remember the data when page is reloaded.
*** Bug 41557 has been marked as a duplicate of this bug. ***
updating component and setting default owner
Assignee: asa → rods
Component: Browser-General → Form Submission
QA Contact: jelwell → ckritzer
Note that this is not a dup of bug 35566, which is really fixed.
Maybe the difference is the password manager popup dialog involved here?

the subject for me is being refilled, but not the text.  maybe we're not 
remembering/refilling textarea values?  cc radha
Reassigning to pollmann@netscape.com
Assignee: rods → pollmann
Giving this one to you Radha - it looks like just an extension of bug 35566.  
I've attached a one-line fix that should do the trick!
Assignee: pollmann → radha
Component: Form Submission → History
OS: Linux → All
Hardware: PC → All
Status: NEW → ASSIGNED
Target Milestone: --- → M17
*** Bug 40104 has been marked as a duplicate of this bug. ***
Fix checked in last week.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I tried it using build 2000062914 and it is not working.  I can see it for a
second, but then the page refreshes again, without the data.  I tried with the
cache preferences set to "once per session" and that did not help.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
neeti, maybe this is related to what we discussed today.
i tried this today with and without cache. I also tried all the three options 
"once per session", "Every time I view", "never". and in all cases I could get 
the form values restored everytime I reloade3d even from the context menu. 

dbeusse, can you provide a test page and your cache settings so that I can 
double check once again.
It's the same URL as the one this bug was opened with (see URL field for the
ezboard url).  Follow the directions at the beginning of this bug's description
and you should see the problem.  I am running on Linux 2.3.99 (on top of redhat
6.1) if that matters.

ckritzer, I would like some feedback on this. Can you verify if this is really 
happening. only in this page or all pages, some peculiar pattern to it? Thanks,
I still see the same problem I reported on 6/5: the Subject line is prefilled, 
but the Comments textarea isn't.  I think this might actually be Autofill's 
fault...morse could you check into this, please?
hey hey hey
Whiteboard: this is a test
Radha, on Win98 2000-08-02-05-M17 Commercial build:

At the given URL (above), nothing will be saved if you select "No" in the 
Password Manager Dialog (Yes, Never for this site, No) while performing the steps 
to reproduce.  If you select "Yes", then only the subject field is saved.

However.

When I went to google.com, did a search, and hit the back button, the info was 
saved, and when I went to bugzilla (using this bug form), added my previous 
comments ('this is a test' to the Status Whiteboard & 'hey hey hey' to the 
Additional Comments section), committed them, and clicked the back button, all 
the information was retained. 

I think the URL supplied may be a special case, and it requires some further 
investigation.  I will look into it today, 08.03.00.
Whiteboard: this is a test
Password manager can make things better but not worse.  If you have instructed 
password manager to save the form previously, then it will prefill in the fields 
when the form is returned to.  But it will not erase anything that is 
already filled in for that form.

So that explains why it works when you click on password manager's yes button.  
The subject field (along with username and password) were all saved and so they 
get prefilled on next visit.  This is true whether it is from the back button or 
if the next visit actually occurs in a new browser session.

The reason you were seeing the subject field restored and nothing more (the 
more is the comment field on that page) is because password manager 
saves text and password fields only.  It does not save textareas nor checkboxes.
Status: REOPENED → ASSIGNED
Target Milestone: M17 → M19
IMO, marking this M19 which means post 6.0 ship is a mistake.  As the reporter 
mentioned, "most web sites use the back button to make corrections."  Bugzilla 
is a good example of that.  Make a mistake such as entering a bad e-mail address 
for someone on the cc line and mozilla tells you to hit the back button and 
correct the mistake.  However you will have lost everything that you entered due 
to this bug.  Nominating for nsbeta3.
Keywords: nsbeta3
nav triage team:
ckritzer's comments suggest that this now works the way it should, so nsbeta3-.
 QA/ Chris, if you can find more examples of this problem popping up (as
describe by Blake), renominate by removing the [nsbeta3-] from the status.
Whiteboard: [nsbeta3-]
So if ckritzer is saying that is working the way it should, why is the bug not 
being closed out as fixed?  Either it is working and is fixed or it is not 
working and should be done for beta3.  Renominating.
Whiteboard: [nsbeta3-]
nav triage team:
works for me
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Using what url and steps?  How about the url and steps I outlined when I filed
this bug?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Confirming what Don Beusee said.  Problem indeed exists on the URL he cited.

However problem does not exist on bugzilla for example.  So what is unique about 
his url and how common would that be for other urls?
Well for one thing, the html on the cited page is incorrect.  There is <font> 
tag and then later on are three </font> tags.


If that is causing it, it should not be a serious enough error to cause problems
like this.  There will be errors like this on LOTS of web sites.  Even though
the html is not perfect, it works with NS4 and IE, so Mozilla aught to be able
to tolerate it without these types of side-affects.
Whatever causes my url to behave that way, Mozilla should work properly, since
NS4 does, and this is the only point that matters.  And yes, this is serious
enough to fix before the next milestone.

nav triage team:
This bug is really about Back and Forward behavior with some web pages, so
changing summary.  We should remember the form data when you go back and forward.

[NEED INFO] Does this only happen on rare pages or is it a more common problem?
Summary: Forms do not remember the data when page is reloaded. → Forms do not remember the data when go back on some pgs
Whiteboard: [NEED INFO]
Nav triage team: Possible duplicate of 50143, which we've plus'd. Minusing this 
one because we don't have an answer to our "need info," and we're not sure this 
is seen on any other test cases.
Whiteboard: [NEED INFO] → [NEED INFO] [nsbeta3-]
(Hope this is getting fixed soon, I hate re-typing error reports in bugzilla)

I can reproduce this bug with bugzilla, so I'd say it's a very common bug.  To
reproduce in bugzilla, do this:
1. type something in "additional comments" box for this bug.
2. Hit "view bug activity" link (it's right under the commit button).
3. Hit back button.
Notice your additional comments are GONE!  So there you go.  I just did this
with the latest build (2000091312).
So can you "plus" this bug now? (whatever that means)
Whiteboard: [NEED INFO] [nsbeta3-] → [nsbeta3-]
I could not reproduce the problem with bugzilla. Nobody else who have commented
earlier in this bug could. I don't believe there is a serious flaw in the form
value restoration code. My best guess is, the JS in the URL above probably
clears the fields.
Severity: major → normal
Priority: P3 → P5
Please don't make such erroneous assumptions about what the web site is doing
without proof.  As I said, it works in NS4, so obviously the JS is not clearing
the fields.
There are other people that CAN reproduce it and they point to areas in mozilla
that could be causing the problem.
I cannot use mozilla with this bug pending.  If that is not good enough to keep
this bug open at a decent priority, I don't know what is.
Priority: P5 → P3
It happens to me too on PhpMyAdmin (a php-based web tool to admnistrate MySQL
databases).
And there is no JS here to clear the form.
(build 2000120521)
nav triage: p4
Keywords: nsbeta1
Priority: P3 → P4
nav triage team:

Marking nsbeta1+
Whiteboard: [nsbeta3-] → [nsbeta3-][nsbeta1+]
QAContact -> claudius
QA Contact: ckritzer → claudius
Target Milestone: --- → mozilla1.0
Eric, Docshell is saving the Historylayoutstate when the page goes away and 
restoring it back from SHEntry when it is loaded again. I don't understand why 
the form values are not restored. Can you take a look if something goes wrong 
down in presShell? 

Also, you don't have to press the "add topic" button to see the problem. Just 
fill in some values in the text fields, go elsewhere and get back to the page 
thro' back or forward or even simply reload the page to see the problem.
Assignee: radha → pollmann
Status: REOPENED → NEW
Eric, did the other bug about the same problem also fix this one? (Broken forms
don't restore data when going back)
Is bug 93413 a dup of this one?

Please note that the report changed a little, see my last comments on the bug to
see how to reproduce (2001-08-11 19:20 and 2001-08-12 12:20). If this is not a
dup, should I file a new bug with a better description?

I'm asking here as a suggestion of basic.

Marcos.
mdimitrio: I'm not sure now. That bug has a very specific reproduction pattern,
and it would be great if somebody here could check it out - it's easy to
trigger, and 100% reproducible. 
*** Bug 99258 has been marked as a duplicate of this bug. ***
Please see bug 99638, which may be related.
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov
Blocks: 104166
Summary: Forms do not remember the data when go back on some pgs → Forms do not remember the data when go back on some pgs[form sub]
Just wanted to note that this is starting to happen in more and more pages. For
instance in slashdot, if you hit preview, then back, the comment you entered is
gone. This was not happening in the past.
ok lets get some traction on this. 1st the URL doesn't work and this bug report
is real old. I'm seeing this problem still with the forms at slashdot.org
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
The URL 404's. The HTML is archived at 

http://web.archive.org/web/20000901031156/http://pub4.ezboard.com/fiwetheyopenforumiv.showAddTopicScreenFromWeb

but I don't know if that's all we would need to reproduce the bug.

If that is all we need, then it worksforme using Windows 98, 0.9.7, Build ID:
2002012503. 



When a form is loaded inside a frameset (on Mozilla 0.98 win32), 
it appears to have two different sets of saved field values.  You can
alternate between these two sets by pressing the refresh
button.

The attached sample demonstrates this.
The refresh-related form data lossage test case
I just submitted is a zip file containing a frameset
and two documents.  Bugzilla seems to have lost the
extension so you will have to rename it.

- David Ziegler
Keywords: dataloss
any update on this ? Perhaps fix for bug 138892 can improve things ?
did anyone checked the cache-control flags in the response headers?
Note 1:
For list boxes and other similar select-type fields:  when the listed values are
changed on the client-side (e.g., using JavaScript or something), it seems that
their selections will not be remembered on back/forward/refresh.  See Bug 119324
(just thought some people might like to know so they will be more mindful of
that issue when they want to comment on this report).

Note 2:
Using Win 98, Build 2002050608, so maybe the example for 0.9.8 doesn't apply, but...
I do not get the alternating data in the example frameset's form.  What I get is
when I hit enter, then back, the data is still there.  When I enter something,
hit refresh, enter new data, and hit refresh again, (and so on, refreshing,
entering, just refreshing) I always get an empty field.
If I choose "This Frame ->" from the context (right click) menu on that bottom
frame with the form, and choose "Reload Frame", the data in the field remains
unchanged.  Maybe the problem now is that reloading a frameset doesn't
recursively reload the individual frames the same way we would reload them
individually.. (different bug)?  Comments?

Note 3:
Could not determine if this is still an issue at http://slashdot.org/ , etc.
(Comment 45).  Can anyone comment on that specifically?  In fact, it would be
good if anyone could give an example of this bug not related to Bug 119324.
Appears to be related to having two forms on one page... the first form
maintains its data when using "Back," the second does not.  For examples see the
test page

http://java.grayson.com/testform2.html

Enter any text in the "search" field in the upper right, submit and go back. 
The text will still be there.  Enter any text in the textarea field further down
the page, submit and go back.  The text will be gone.  For an example of the
same page without the first "search" form (which works as expected), see

http://java.grayson/com/testform3.html

I noticed this on photo.net and made up these test forms.

*sigh*  Forgot the details... Win2000, build 2002041711.
Appears to be related to a bug jkeiser owns (probably fixed recently).
I don't think it is related to the first form (bug 138892). On
  http://french.imdb.com/list
settings in 3, 4, 5 are remembered, but not those in 1 and 2.
This bug is coming into focus.  I have taken apart the source code for the
example URL Vincent gave (Comment 57), and I find that Vincent is mistaken:  the
fact that there are two forms is definitely important to this example.  (I will
email anyone who wants to know with more info, but otherwise please accept that
having two forms is the deciding factor, although the exact nature of the buggy
behavior varies.  If you require a quick demonstration, observe that for
Vincent's example, values _anywhere_ on the big form will be forgotten and even
sometimes magically restored if you refresh the document enough times.)  I am
using Win 98, Build 2002050608.

Let me run down some observations:
- Even though the forms-in-frames bug (Comment 49/50) is still present, that
report belongs in Bug 133946.
- Even though user selections are not remembered for some script updated select
lists, such reports also belong in some different bug (I don't yet know which
one; _not_ Bug 119324 as I originally misunderstood, see Comment 53).
- Outside of such special cases, Mozilla seems to remember form values just fine
if there is only one form on a page.
- I don't see any form forgetfulness for the example URL in this bug's info (or
the substitute archived URL given in Comment 48), except that the form's
password field is deliberately "forgotten" (it has type="password" so that is
okay).  Does anyone else still have problems with that URL?
- On further investigation, I find that the forgetfulness effects seen in forms
at SlashDot (Comment 45) also involve two forms, exactly like Vincent's example
(Comment 57), and also just like the photo.net pages (Comment 54).

In short, I feel that this bug is obsolete in its current form.  Yet it
currently invites everyone to report any kind of behavior relating to "forms do
not remember the data when go back on some pgs" here, even though closer
investigation shows that there is enough detail to classify those bugs under
more specific headings.  There are other bug reports, and more could be opened,
to deal with specific cases if either of my solutions is adopted.  I therefore
propose changing this bug in either one of the following ways:
- Turn it into a proper tracking bug for form value remembering bugs (not to be
confused with a tracking bug for all session history bugs); its summary hardly
needs to be changed at all; but its example URL should be removed.
- Resolve it wfm, since the original problem URL does not seem to be a problem;
consider creating another bug to be the tracking bug for this kind of problem.
For one last time, I'm going to register my objection that this bug is still
open.  Here's why it should be marked RESOLVED WORKSFORME:  
- The example URL wfm on Win 98, Build 2002061908 (reporter:  how about you?)
- The attached testcase (attachment 73230 [details]) falls under Bug 133946
- The form value forgetfulness in Comment 57 falls under Bug 138892
Someone please close it (unless someone can give a good reason why we shouldn't;
I'm all ears...)
This is working for me on Mozilla 1.0 and 2002062004 trunk Windows 98. Resolving
worksforme, consistent with the comment above. Look to the bugs mentioned there
for the remaining problems.
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → WORKSFORME
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: