182286 - Form element values get restored when cache contror flags try to prevent that.

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[James Drabb]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126

I stumbled across a cache problem with Moz 1.2b and just tested against 1.2.
The problem is that when a page is submitted the posted data comes out correct. 
However, if you press back, change some parms and re-submit, the new submitted
data as well as the old submitted data appears.  I have two pages to
demonstrate this problem.  The first html page can be downloaded here:
http://web.tampabay.rr.com/jdrabb/TimeOff.html
The next page will require a working IIS setup since it is an asp page to
process the posted data.
http://web.tampabay.rr.com/jdrabb/TimeOffInsert.asp

Save both files under your wwwroot directory and open TimeOff.html.
Select a date from one of the calendars, say 12/12/2002 and submit the
form.  The asp page just spits out all the posted form variables.  Now
press the back button and all the calendars should have no dates selected.
You can hit refresh if you want.  Now pick a second date say, 01/03/2002
and submit the form.  Now instead of only seeing a value for 01/03/2002
the data posted is actually the data from the previous post 12/12/2002
and 01/03/2002.

Reproducible: Always

Steps to Reproduce:
1. See "Details Section"
Actual Results:  
Invalid data

Expected Results:  
Correctly posting forms values

Comment 1

[Alexandru Savulov]

reproter,

have you tested this with various cache settings? have you tried to turn off
cache entirely? it will take me some time to setup the test environment so i'd
appreciate if you could test with cache turned etnirely off. (make sure that
also disk and memory settings for cache are 0). thanks!

Comment 2

[James Drabb]

I have tested it with all cache settings, closing the browser between cache
setting changes to be certain.  The same problem still happens.  Clicking
on clear memory cache or clear disk cache have no effect and the same problem
persists.  The only way to have the form post properly is to close the browser.
It works properly with or without quick start.  However, it only works the FIRST
time the form is posted if you post the form a second time, the same problem
happens.  I plan on testing with the Linux version of Moz 1.2.
I tested it with Apache 2 and PHP and I get the same problem.  Here is the
PHP script to spit out the posted vars:

<?
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");

while(list($key,$val)=each($_POST))
{
	echo "$key = $val<br>";
}
?>

Comment 3

[Alexandru Savulov]

i see what you mean, however I didn't had the time to read the JS in the html
document. you don't have to restart the browser, in order to refresh a page hold
down SHIFT and click on the refresh button. this will cause the fetching of the
page from the server ignoring anything that might be in the cache. i will look
further into your javascript and try to get a simplified testcase that does not
require ASP. thanx for reporting this bug.

Comment 4

[Alexandru Savulov]

the testcase posted by reporter uses style information to fill in the values for
every of the hidden inputs. the thing works pretty much like this:

- every TD contains a hidden input
- when the user clicks on the TD some JS code is using the style info (value of
the [class] attribute to set/reset the value of the hidden input
- after one submitts the data and hits back, the initial document will be
reloaded with the initial style data (that is correct),
-  _BUT_ the way form data is restored  in mozilla/netscape is that we restore
the values of the inputs at the moment of submission (not the initial values
when the document was first loaded). this is the way mozilla works and it won't
change.

thus:

- the bug needs to be marked invalid (no offense meant)
- I recommend the use of flags like no-cache in the HTTP header (or <meta> tag)
to prevent the caching of the hidden inputs values

Comment 5

[James Drabb]

In reply to: Additional Comment #4 From Alexandru Savulov

"_BUT_ the way form data is restored  in mozilla/netscape is that we restore
the values of the inputs at the moment of submission (not the initial values
when the document was first loaded). this is the way mozilla works and it won't
change."

I think that this is _very_ flawed logic.  The fortune 100 company I work for
just dropped mozilla as a candidate for a standard corporate browser because of
this issue.  Do you think that the logic of "restoring values of inputs at form
submission" is valid?  I think that if a user clears all their cache, sets
memory and disk cache to ZERO and chooses to NEVER compare a page to the cache,
that the browser should NEVER restore values.  Period.  I have not seen one
other browser that has this problem other then Moz.

"I recommend the use of flags like no-cache in the HTTP header"
This has NO effect on the outcome.  Mozilla still displays INCORRECT results.

So let's try to understand your thinking about this bug:
1.  Users uses NO CACHE at all
2.  Meta tags say to NOT CACHE
3.  Mozilla ignores these directives
4.  Mozilla adds values to a form submittal that are NOT THERE
5.  You say this is not a valid bug?

Comment 6

[Alexandru Savulov]

no-cache should work. investigating.

Comment 7

[Alexandru Savulov]

yeah, looks like reporter is right (and I had a flaw in my logic), i didn't had
time to go trough his testcase last night so I stated wrong things. mozilla is
restoring the values when browsing back to the document that contains the form
(so does IE 6), but it shouldn't given the HTTP flags specified there. I haven't
tested with Opera, earlier IE releases, or other browsers. we'll see when we can
fix this.

Comment 8

[Vladimir Ermakov]

to jkeiser

Comment 9

[Carine Held]

Attachment: Test case HTML

Comment 10

[Carine Held]

Attachment: Test Case asp

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.