Mark Jones Reporter
	Description • 23 years ago

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://63.140.143.76/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)

	Aaron Kaluszka
	Comment 1 • 23 years ago

They told me INVALID, but maybe they'll listen to your arguments

*** This bug has been marked as a duplicate of 85165 ***

	Radha on family leave (not reading bugmail) Assignee
	Comment 2 • 23 years ago

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. 

	Radha on family leave (not reading bugmail) Assignee
	Comment 3 • 23 years ago

I'm having trouble accessing this link. Can you provide a working link?

	Mark Jones Reporter
	Comment 4 • 23 years ago

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.

	Darin Fisher
	Comment 5 • 23 years ago

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.

	Mark Jones Reporter
	Comment 6 • 23 years ago

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.

	Radha on family leave (not reading bugmail) Assignee
	Comment 7 • 23 years ago

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. 

	Radha on family leave (not reading bugmail) Assignee
	Comment 8 • 23 years ago

BTW, you don't need any cache control mechanism to achieve what I have described
above. 

	Radha on family leave (not reading bugmail) Assignee
	Comment 9 • 23 years ago

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.