156684 - cache control causing form to clear when using back button

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[BugZilla User]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020709
BuildID:    2002070913

(the following is from a usenet post i refer to:)

you probably need to be a livejournal user to test this (as that's the only
example i have right now).

the problem occurs when i go to reply to someone's journal post.  i get a page
with a form.  i fill it out, hit the PREVIEW button, and another page loads.  it
tells me to use my BACK button if i want to fix anything.

the problem is that when i hit BACK, the previuos page's form is cleared!  (i
went to a site i made that has simple forms and this does not occur.)

AND.. it only does this for me using mozilla.  IE55 and NS479 don't do it.

i checked for javascipt in the livejournal page and i don't see any. i've been
up and down mozilla's preferences (thinking maybe it had something to do with
form-saving) and i'm truly stumped.

Mozilla 1.1a+
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020709


(REPLY #1:)

I have also noticed this issue with livejournal. however, mozilla doesn't
generally do this, it's just for that page.

there's no script in the page, but the form page is served with a header like this:

HTTP/1.1 200 OK
Date: Wed, 10 Jul 2002 09:55:45 GMT
Server: Apache
Cache-Control: private, proxy-revalidate
ETag: "be598bf68d8f09f3d4fc93e1d34882d7"
Content-Type: text/html; charset=utf-8
Content-Language: en
X-Cache: MISS from www.livejournal.com
Connection: close
Transfer-Encoding: chunked

I'm guessing that the cache-control header is making mozilla reload the
page, and so clearing the form, but I'm not sure.  If it is, I'm not sure if
mozilla is doing it wrong, or if IE is doing it wrong (and therefore the
livejournal server would be the issue)


(REPLY #2)

Mozilla is doing it wrong. 'private' means that only private caches like
Mozilla's (as opposed to public caches such as proxies) are allowed to cache the
page. 'proxy-revalidate' means that if a proxy server has cached the page, it
must contact the server to check that the file hasn't been updated before the
proxy passes the cached copy on to a client. 'proxy-revalidate' is redundant in
this case, as 'private' indicates that proxies aren't allowed to cache the page
at all.

Protahn, I suggest you go file a bug at <http://bugzilla.mozilla.org/>. 

Reproducible: Always
Steps to Reproduce:
1.go to the url described
2.put 'test' in the subject box, 'test' in the message box.
3.hit the PREVIEW button.  you are told to use the BACK button if you want to
fix anything.
4.hit the BACK button.  the form is cleared (arrrrrgh).

Actual Results:  the form is cleared.

Expected Results:  the form should have the data you typed into it restored so
you can edit and re-submit.

the usenet thread on this (the one that suggested i file this bug) is here:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=agh0pe%24ladtl%242%40ID-106624.news.dfncis.de&rnum=1&prev=/groups%3Fq%3Dlivejournal%2Bgroup:alt.fan.mozilla%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dagh0pe%2524ladtl%25242%2540ID-106624.news.dfncis.de%26rnum%3D1

as of this writing it's showing 1 reply but there are actually 2 (google hasn't
caught up to it yet).

Comment 1

[Darin Fisher]

-> radha

Comment 2

[Michael Lefevre]

this now WFM, with a trunk nightly from a couple of days ago, and 1.1beta, both
on win2k.  as far as I can see, the livejournal site and headers haven't changed.

(I posted reply #1 in the quoted usenet thread above BTW)

Comment 3

[BugZilla User]

ditto (WFM=works for me?)

i'm the bug poster, and as of 1.1b this seems to be fixed (*jumps up and down*).

i'm not sure what it was, i even used Proxomitron to filter out those cache headers (i think, i'm not an expert at it) and it didn't seem to matter...

oh well.

Comment 4

[Radha on family leave (not reading bugmail)]

Marking fixed based on the previous comments.

Comment 5

[Tom Everingham]

verified