89309 - Reload POSTed page doesn't rePOST or popup dialog, just re-renders

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[Robin Green]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628
BuildID:    2001062823

When you submit a form using HTTP POST, and then click the reload button,
confirmation dialog is not shown. This could cause multiple purchases on
badly-designed ecommerce sites, e.g. buy.com. Correct behaviour occurs, however,
if you hold down shift while clicking reload.

Reproducible: Always
Steps to Reproduce:
1. Note: I am connecting through a proxy - this may be relevant.
2. Go to URL above
3. Enter some text
4. Click translate button
5. When page has finished loading, click reload button on button bar.

Actual Results:  Immediate reload.

Expected Results:  Should display the dialog box saying: "The page you are
trying to view contains POSTDATA..." and asking for confirmation before doing
the reload.

Workaround: Shift + Reload

Comment 1

[timeless]

i'm not sure who should own this, but i'd like some comments from UID.

Comment 2

[Andreas M. "Clarence" Schneider]

Actually, the data seems not to be reposted without shift, even if the page has
a "no-cache" header. It is treated like navigating in session history.
Testcase: http://clarence.de/post-test/form1.html (select "Data included").

The distinction between "reload" and "shift+reload" does not make sense for
POSTs. IMO a simple reload should be treated like a shift+reload for POSTs,
because we can't validate it without performing a repost and the user has
just told us to validate it (that's what "reload" actually means).

Confirming with 2001-07-12-14, Win NT. OS -> all.
Lowering severity because I don't think this can really cause multiple
purchases or similar bad things.

Comment 3

[Robin Green]

changing title to reflect Andreas' comments.

Comment 4

[Matthew T (active 1999-2002)]

The reporter is correct: as in other browsers, the alert should be shown on a 
simple reload (though QA should check that it does *not* appear when merely 
going back or forward past such a page which has expired from the cache).

However, the appearance and content of the alert must be cleaned up first; for 
the alert to appear in its current state would be considerably worse than the 
current behavior of it not appearing at all.

+-------------------------------------------------+
|:::::::::::::::::::::::::::::::::::::::::::::::::|
+-------------------------------------------------+
|   ,   This page cannot be reloaded without      |
|  /!\  resending the information you entered.    |
|  """  Are you sure you want to continue?        |
|                                                 |
|                         ( Cancel ) (( Resend )) |
+-------------------------------------------------+

If you wish to deal with that in another bug, please make it block this one.

--> Form Submission

Comment 5

[rods (gone)]

Over to eric

Comment 6

[Radha on family leave (not reading bugmail)]

When a post data result page is reloaded, we do not repost it to the server ie.,
we will not duplicate a credit card purchase or whatever.  Session History holds
a handle to the postdata and passes it to cache. I don't know how cache
validates a postdata result, but we definitely do not repost to the server. The
'no-cache' behavior has recently changed. Please check in a recent build.

Taking from evaughan. 

Comment 7

[Ferdinand]

*** Bug 99708 has been marked as a duplicate of this bug. ***

Comment 8

[Philip Tellis]

IIRC, the HTTP spec requires that POST requests not be cached.  What I
understand from this, is that every reload must resubmit the form to the server.
 Hence, whether you want to or not, you MUST duplicate credit card purchase, and
MUST NOT store the page in cache.

Philip

Comment 9

[Alec Flett]

protocol specs to not dictate usability. they say "should not be cached" but it
does not say "the reload button in an agent should not rerender the page"

Comment 10

[Darin Fisher]

exactly.. the useragent is free to decide when it re-renders a page.  we may
decide that the reload button should actually contact the server again, but no
matter what, that decision is completely in the hands of the useragent.

Comment 11

[timeless]

there's a distinction between CACHE and HISTORY. the USERAGENT may not CACHE 
POSTs but i think it may HISTORY them. these are all techincal terms however 
i'm not a spec reader/writer, i'm a bug reader.

Comment 12

[Darin Fisher]

it sounds like we've gone down a tangent here... the real bug IMO is what reload
means for a POST result.  if we look at other browsers (4x for example) reload
means: popup a dialog to ask the user if they want to resubmit, and then if yes,
resubmit the POST request.  the POST request should (obviously) never be
re-issued without user confirmation for the reasons radha outlined.

radha: what do you think?

Comment 13

[Radha on family leave (not reading bugmail)]

Post data results are kept in HISTORY, not in CACHE.We currently throw the
dialog asking user's confirmation to repost only if the page has expired from
cache. Otherwise, on a simple reload,  the postdata stored by history is applied
on to the page without resubmitting to the server. 
Both Nav 4.x and IE6 throw a dialog on a simple reload of a post data result. 
I think this is do-able from history's perspective.

Darin: Would there be an issue with Cache?  How do I make the cache to go out
and repost the data with out changing the loadType?

Comment 14

[Jesse Ruderman]

When you reload any page other than the results of a form post, the server is 
hit (although it may respond with "not modified").  It's confusing that Mozilla 
redisplays the page without reloading it without hitting the server, especially 
since the result of a form post is likely to be dynamic.

Comment 15

[Darin Fisher]

radha: you only need to ensure that the VALIDATE_ALWAYS load flag is set (which
should already be set for a reload).

Comment 16

[Radha on family leave (not reading bugmail)]

VALIDATE_ALWAYS is done currently. Also, for reloads on post data results, the
second argument to SetCacheKey is passed PR_TRUE, indicating to load the page
*only* from cache, as in
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#4558. I
guess this should be false if the user gave permission to repost to the server.
Right? 

Comment 17

[Darin Fisher]

radha: right, the second argument to SetCacheKey should be FALSE if the user has
confirmed that re-POSTing is ok.

Comment 18

[Radha on family leave (not reading bugmail)]

This is session history.

Comment 19

[Radha on family leave (not reading bugmail)]

Attachment: Patch to docshell

Comment 20

[Darin Fisher]

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

radha: the code which sets cacheFlag should be moved inside the if (cacheChannel && cacheKey) block.
otherwise, r=darin

Comment 21

[rpotts (gone)]

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

sr=[e-mail]

Comment 22

[Radha on family leave (not reading bugmail)]

Fix checked in.

Comment 23

[Ashley Bischoff (blog at handcoding.com)]

*** Bug 95205 has been marked as a duplicate of this bug. ***

Comment 24

[Vladimir Ermakov]

verifying 2001-10-12-05 windows 98 branch

Comment 25

[Tobias Brox]

I have never encountered this before, I've always been getting the dialog. 
However, it is reported that Firefox 1.0.0 for windows is re-posting without
showing any dialog.  Well, firefox 1.0.3 is out, but I think firefox 1.0.0 was
released some years after this bug was reported fixed?