From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001280110 This bug happens if you're on a page with a form, and submitting that form redirects you back to the original page (ie Add Comments box or something). I suppose it could also happen if a normal link redirects you back to the original page, but that's much less common. When you end up back at the form page, the elements should contain the default values (as specified in the source). Instead, they contain the values from the previous version of the page. This might be a symptom of a general History bug: Both the original and the new Form pages should be in the History (though with the same URL), but only one shows. Note that the page returned can be different, but form elements of the same name are filled in instead of defaulted. I notice that the same thing happens if, instead of submitting the form, I follow a link that refers to the original page. Is it intended that self-refferential links are not placed in the history? This could cause havoc with some dynamically created web services, where suddenly the Back button doesn't work as expected. (Though I *suppose* you could blame that on the design of the service) Reproducible: Always Steps to Reproduce: 1. Go to a form with the appropriate behavior (http://188.8.131.52/Gecko_bugs/Form_defaults/index.html) 2. Edit the fields from default. 3. Submit the form. (Or follow a link that refers to the original page) Actual Results: The form fields on the new page contain the values you supplied before submitting the previous page. Expected Results: The form fields should be in their default state, as this is a new page request; it just happens to have the same URL as a page you've visited previously. This bug could become very important to people using scripting to create interactive web sites, which is how I discovered it. The same URL could generate vastly different pages, or even very similar ones, but each should be treated as a new and unique page request by the browser. (excepting for caching issues, of course)
They told me INVALID, but maybe they'll listen to your arguments *** This bug has been marked as a duplicate of 85165 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
I think this could be achieved by using "Cache-control: no store" mechanisms in the page. These directives prevent session History from storing the values of form elements and restoring them back when the page is loaded again. (see bug 93027). As far as cache is concerned, there was an issue with differentiating urls based only on their postdatas. But I believe this was fixed by the new cache. cc'ing pollmann and darin who may be able to answer this.
I'm having trouble accessing this link. Can you provide a working link?
Sorry; that server's having odd firewall problems. I've moved the example to a new location. Note also that adding the following code does not seem to change the behavior: <meta http-equiv="expires" content="Thu, 1 October 1998 00:00:00 PST"> <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> <META name="Cache-Control" value="no-cache, no-store, must-revalidate"> ( also tried *just* cache-control: no-store, as suggested; still no effect. Am I doing this wrong? ) Also, the way my example works, there is no formdata on the problematic page. The form is submitted to one page which redirects back to the original page. There is no URL or Form data differentiating the pages, it is simply a new page that happens to have the same URL as the last one.
mozilla does not pick up these HTTP-EQUIV's in HTML <META> tags.. see bug 90288. but, if you configure your server to actually send these headers, then you'll indeed see their effect.
Okay, the meta thing is a seperate bug (I also haven't yet had any luck with actual headers, but that's probably just me; haven't had much time to play with it). What concerns me is that I shouldn't need to go though all my old stuff and add Meta tags just to make it behave the same way. This sounds like Microsoft saying we can always use a meta tag to turn off their SmartTags. Why change functionality that users (and developers) are used to if there isn't a standard to be adhered to? At very least, every page that is reached though a form submission should get its own history entry. IE 5.5 appears to behave this way. This would probably solve the problem of form fields showing the wrong info.
I visited your newlink, it is little confusing. But I do know that forms with postdata that post to itself are treated correctly by session History. When you have a form that posts to itself, both the urls, (the old one with out the postdata and the new one with the postdata) are considered different urls and both will be added to sessionHistory with their respective form values. The new page will be loaded with default values and the old page will be saved with the form values that were entered. You can go back and forward between them and see the right data.
BTW, you don't need any cache control mechanism to achieve what I have described above.
This works fine in recent builds. When I submit the form, I get a new form with the default values and not with the previous values I had filled in. However, since new page is the same as the old one, it is not added to session history.
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.