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.

*** Bug 41557 has been marked as a duplicate of this bug. ***

updating component and setting default owner

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

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!

*** Bug 40104 has been marked as a duplicate of this bug. ***

Fix checked in last week.

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.

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

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.

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.

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.

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.

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.

nav triage team: works for me

Using what url and steps? How about the url and steps I outlined when I filed this bug?

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?

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.

(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)

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.

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.

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

nav triage team: Marking nsbeta1+

QAContact -> claudius

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.

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

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)

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

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.