The `repost form data?' dialog (for example, when you click the back button to return to a POST-generated page) has buttons labeled `OK' and `Cancel'. This is misleading as `Cancel' implies not loading the page at all; they should be labeled `Yes' and `No'.

But `Cancel' *is* not loading the page at all. If the page is in the cache, then you shouldn't get this dialog anyway, unless you choose Reload. `Yes' and `No' are just as bad as `Ok' and `Cancel', because `Would you like to continue without reposting the form data?' would use exactly the same buttons with exactly the opposite effect. Seamonkey convention is to use a meaningful verb for the main action button. I suggest `Repost' and `Cancel'.

Sorry for being unclear. What I meant by "not loading the page" was "not displaying it on the screen; not taking any action at all", as opposed to "not fetching the page again from the network."

Decklin is right -- pressing 'cancel' does not actually cancel the action. It merely continues without posting form data, opening the door for some potentially ugly results. However, if cancel *did* cancel and leave you at the original starting page, users would be stranded. They'd click 'back' again and be faced with the same dialog. The advantage to the current behavior is it still navigates the history, meaning that users can continue navigating without reposting form data and without having to know about or use the history menu. Therefore, I recommend following Decklin's suggestion and changing the text labels to 'Yes' and 'No.'

Ok, that makes sense. As a side issue, if `No' refetches the URL but without reposting the form data, that's a different bug -- it should be doing the 4xp thing and showing a placeholder page (a la bug 28586) telling the user that the data wasn't reposted.

Eric, this may not be yours, but you will know who to send it to.

Radha, this seems like a session history/webshell thing. Can you take a look? Thanks!

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

I have another suggestion for a solution to this bug, which may or may not make sense to non-power-users (comments?): - "Yes": repost form data, go to page in question - "No": go to page in question without reposting form data (current "Cancel" behavior) - "Cancel": don't do anything The "Yes"/"No"/"Cancel" triad is not without precedent, but I can't think of other examples right now.

I'd like to voice support for Matt's suggestion of three buttons. The current behaviour of "cancel" doesn't actually cancel the quested action (traversal up the browser history chain). This confused me the first time I decided not to repost form-data...I expected to remain on the same page. To me, "No" would imply: "show me the page as it was rendered from the _previous_ post"...there are situations where one would want to do this.

I like the 3 button idea too. I need to look a little deeper to get that going. I will do that after taking care of my beta3 list.

Note that the Cancel button currently is broken by bug 46338 and causes a HTTP GET on the page in question. I like the 3 button idea too, but "No" should not continue the broken "Cancel" behaviour. It should fetch the page from cache. If it's not in cache for some reason, the dialog should not present the "No" button. If present, the "No" button should be the default button. "OK" / "Yes" can have side effects like buying the same thing twice.

I'll second Clarence's notion ... going back to the site with GET makes no sense whatsoever and would be confusing to users. Also, given that this bug and bug 46338 are pretty much identical, I think this should either be marked nsbeta3+ or duplicate of that one. And frankly, the comments here are clearer on what is going on, so I think that one should be a duplicate of *this* one. Here is a URL to a testcase I created in bug 47924: http://www.ieffects.com:8080/cgi-bin/mozbug1.pl. Go to the URL, click Submit. Yo yo man appears. Reload. Hit Cancel on the "repost form data?" dialog. Yo yo man disappears because it has gone back to the server with a GET, losing the hidden parameter.

To make the message make sense, we could add something to the effect of: "Pressing 'yes' may cause the action you performed by loading the page to be done a second time." This addition makes slightly more sense if you get the warning after pressing reload on a placeholder page (as opposed to pressing on the page after the page that was posted to).

Forgive me if the following has already been addressed, but: I'm almost centain that I'd rather have the back-button NEVER result in a network transaction. I'd like a preference so that I need not be bothered with this dialogue box at all. If reposting is what I want, I'd submit the form after going back. Can we make a preference so that the back button merely redisplays the previous HTML, as was the case in Navigator 4.x?

...so long as the page is in the cache, of course.

Comments from bug 47924 by John Keiser: From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m17) Gecko/20000804 BuildID: 2000080404 When you click refresh on a POST form, the dialog box has "Cancel" on it but when you click Cancel it still goes back to the server with a GET response. Cancel implies to me (and probably many others) that the operation will not proceed; something more like Yes / No / Cancel or even just Yes / No would be more appropriate in this case. And steps to repro: 1) Launch browser 2) Load http://www.ieffects.com:8080/cgi-bin/mozbug1.pl 2a) A page loads with only a 'submit' button on it 3) Click on 'submit' button 3a) A security alert dialog comes up. 4) Click 'OK' button on security warning 4a) A second page loads with 'Yo yo man' in H1 and a 'submit' button below it 5) Click on the 'Refresh' button at top of window 6) Click 'Cancel' button on security warning

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

See my comments in bug 46338.

pohl: The 4.x behaviour you described occures only if the result of the post is a HTTP 3xx response. Now Mozilla behaves so too (see bug 46338).

Updating QA contact.

pohl: I agree. I find it really annoying that it pops up all the time. It would be good to be able to set a default action as a preference which could be over ridden. I know when using IE I never get prompted to repost. This is especially annoying when using on-line systems that require a lot of back and forwards - it really impacts your speed in using such a system.

I have to revise my previous opinion: We should not present a dialog at all in this situation. Instead we should always present the old result of the POST, even if it's not cachable (are we able to do this now?). A way to notify the user that the contents of the page are stale would be a message in the status bar. If a user wants to repost the data, he/she can go back to the form and submit it again or click reload (in the latter case a warning would be appropriate). RFC 2616 (HTTP/1.1) says (and I agree): --8<---- 13.13 History Lists User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session. History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents. This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. Note: if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider it important that users not be presented with error messages or warning messages when they use navigation controls (such as BACK) to view previously fetched resources. Even though sometimes such resources ought not to cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects of improperly functioning history mechanisms. --8<----

Discussion seems to have moved to bug 55055.

Post RTM work. This dialog is going to go away. Markign this a dupe of 55055 which currently tracts the reposting problem. *** This bug has been marked as a duplicate of 55055 ***

Verified dupe.