135289 - Meta http-equiv tags w.r.t. cache control and forms not working properly

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Tom Everingham]

Overview Description:  After submitting a form which uses <META
HTTP-EQUIV="Cache-control" CONTENT="no-store"> to control caching, and then
hitting the back button, text boxes should be wiped clean.  This works properly
if the Cache-control is sent via http headers directly.

Steps to Reproduce:
1.)  run the attached script
2.)  fill in the text and password box
3.)  click submit
4.)  click on back button

Actual Results:  the text box is pre-filled with what was previously entered

Expected Results:  it should be wiped clean

Build Date & Platform Bug Found:  2002032720 all platforms

Additional Information:  attaching the script, I have this set up on an internal
site but I can't supply the link here, sorry.

Comment 1

[Tom Everingham]

Attachment: perl script to demonstate problem

Comment 2

[Oliver Klee]

Bug 134029 may be related.

Comment 3

[Radha on family leave (not reading bugmail)]

Darin, If I remember right, HTML <Meta HTTP-equiv ... > tags don't work right? 
Is that a bug or is it not supported intentionally.

Comment 4

[Darin Fisher]

meta http-equiv tags probably won't effect docshell's decision to save or forget
layout state.  that decision is made during the necko OnStartRequest event...
meta http-equiv (and other HTML tags) are parsed later on.  so to fix this we
need to some how tell session history to not remember layout state when we
detect one of the special HTTP headers as a meta http-equiv.

Comment 5

[Radha on family leave (not reading bugmail)]

Docshell already has code to parse  <Meta http-equiv="Refresh" ....> tags. I
guess we should add code in Docshell to parse other tags too and let session
history decide based on what was found.

Comment 6

[Radha on family leave (not reading bugmail)]

Here is a internal  testcase site
http://10.169.103.61/webpub/testcases/Caching_behavior_of_Forms.html.

Comment 7

[Radha on family leave (not reading bugmail)]

Among the testcases at the  internal website, I'm not sure why the expected
behavior for testcase #19 (which just uses no-cache) is to have all text fields
wiped clean. IMo, only password field  should be wiped clean and which is how
mozilla currently behaves. 

Comment 8

[Radha on family leave (not reading bugmail)]

Attachment: Patch to docshell

The patch looks for no-store, no-cache flags in the Http Channel in
nsDocShell::EndPageLoad(), and updates the current page's SHEntry with
appropriate flags to save layouthistorystate. This can not be done earlier
because <META http-equiv ...> tags are detected well after we create an entry
for a page in OnNewURI().

Comment 9

[rpotts (gone)]

Comment on attachment 82696 [details] [diff] [review]
Patch to docshell

looks good to me. (r=[e-mail])

Comment 10

[Darin Fisher]

Comment on attachment 82696 [details] [diff] [review]
Patch to docshell

>Index: nsDocShell.cpp

>+            discardLayoutState = ShouldSaveLayoutState(httpChannel);

the name "ShouldSaveLayoutState" is very misleading... you'd expect it
to return TRUE if the layout state should be saved, but instead it
returns FALSE.	how about calling it "ShouldDiscardLayoutState" instead?

with that change, sr=darin

Comment 11

[Tom Everingham]

corrected testcase 19 expected results per radha's comments

Comment 12

[Radha on family leave (not reading bugmail)]

Fix checked in.

Comment 13

[Radha on family leave (not reading bugmail)]

ADT, this bug is about support for <META HTTP-EQUIV="Cache-control"
CONTENT="no-store">. The fix has been in the trunk for while. Please approve it
for the branch.

Comment 14

[Jaime Rodriguez, Jr.]

claudius - can you pls verify this fix on the trunk? thanks!

evelyn/radha - is this issue happening on any top sites, or is this is a
privacy/security issue we wish to resolve? i think i understand the benefit, but
i do not know that it will an issue that has visibility. pls help ME understand.

last, what's ourt exposure here in terms of risk, if we take this fix (i.e. If
this caused a regression, what types of things could be affected)? 

Comment 15

[Radha on family leave (not reading bugmail)]

I have not seen this happen on the top sites. This is more of a missing feature
than a bug fix.  The patch primarily looks for cache control headers in the
httpChannel and sets a flag in nsISHEntry. The worst thing that could happen in
remote cases is the channel giving wrong information about the presence of these
headers and thereby docshell setting the wrong flag in nsISHEntry. I don't see
this patch causing regressions in other areas. The rest of the patch is
consolidation of existing code to use the newly introduced function.

Comment 16

[Claudius Gayle]

VERIFIED Fixed with 20020613 builds

Comment 17

[Jaime Rodriguez, Jr.]

adt1.0.1-. let's try and get this in for the next release.