User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Some pages (blogs) allow to submit a comment and keep the same URL, such as the above URL. When I want to reload the page, Firefox says: "The page you are trying to view contains POSTDATA. If you resend the data, any action the form carried out (such as a search or online purchase) will be repeated. To resend the data, click OK. Otherwise, click Cancel." But I just want to reload the page without resubmitting anything, and neither OK nor Cancel allows to do that. Reproducible: Always Steps to Reproduce: 1. Open a webpage having the described system. 2. Do a form submission. 3. Click on Reload. Actual Results: Firefox opens a box saying "The page you are trying to view contains POSTDATA. If you resend the data, any action the form carried out (such as a search or online purchase) will be repeated. To resend the data, click OK. Otherwise, click Cancel." and having two buttons OK and Cancel. Expected Results: The box should have a third button to reload the page without doing any form submission. As a workaround, I can copy the URL, paste it in a new tab and close the old tab.
FYI, you can use the Go button instead of Reload one in such cases.
Or you can press Cmd+L, Enter.
I think this would be confusing more often than it would be useful, so I vote for WONTFIX. With most POST forms, "reloading" the page without the form data would result in an error message or something else unrelated to the page. With other POST forms (such as the commenting form on WordPress blogs), there is a redirect after you submit the form, to avoid exactly this problem.
(In reply to comment #3) > With most POST forms, "reloading" the page without the form data would result > in an error message or something else unrelated to the page. On the other hand, reloading with form data may also result in an error message, or worse, a second submission that could be unwanted. The solution with the Go button or Cmd+L will not replace the Reload since the page is opened in a new tab (maybe due to an extension, but anyway this is a feature I like very much in the other cases) and doing a real Reload may be necessary in addition to Go. Of course, the 3rd button to reload without submtting form data (or anything equivalent) could be configurable.
The reload with posting is certainly wanted by everyone. But it would be so nice to have checkbox maybe found in the preferences to disable the appearance of this alert window. For "us developers" this would save much time.
it ISN'T wanted by everyone, I even think that reloading page without resend POSTDATA is more secure. I think we need to add the third button AND a checkbox in preferences where everyone can choose between "AutoReload WITH POSTDATA" and "AutoReload WITHOUT POSTDATA", "Warn everytime"
I would really love some configuration options for this. This can be very annoying on the mac platform where the dialogue is animated. If you submitted a bunch of forms offline and then reload them all while online, it takes about 3 seconds/tab to submit everything. I've patched my own build to completely disable this dialogue for this very reason. Since I did not add configuration options, I doubt my patch would be welcome, but I do get asked on a fairly regular basis for a patched build.
Comment 9 is off-topic for this bug, since this bug asks for a way to reload the URL only and not resubmit the form. I think bug 493435 is what you want. Also, the fix in bug 160144 will nix the slow dialog animation by turning the dialog into a content-area page.
I was re-affirming the thoughts in comment 8. That would be ideal, and would address my own concerns, and possibly some of the related bugs you pointed out. Perhaps I phrased it poorly, but the option above for "AutoReload WITH POSTDATA" is exactly what I seek.
When is the reload automatic? Isn't this bug about what happens when you explicitly request a reload by hitting the reload button? Currently, hitting reload on a POST result invokes bug 160144, the modal dialog that allows only "repost" and "cancel". I think adding an option to GET the same URL as the original POST would be an improvement, especially if it includes some explanation and/or provides explanatory links for nontechnical users. Seems to me this and bug 160144 both call for improvements to the response to a request to reload a POST result; bug 160144 calls for the response to use plain english and be nonmodal, and this bug calls for it to have an additional option to GET rather than repeat the POST. This option would also be helpful on bug 569142, show an infopage rather than automatically reload when navigating in session history to a POST result which is not cached.
This button would be nice. The actual message box already explains to user what is POST. I think some of them will understand if we put 'reload with POST' and 'reload without POST' buttons, for sure it will be very varying of the page. But it's better when websites redirect after a POST or have an anti-duplicate system (with timestamp/hash in the form by example).
Posting data or loading a page is not the same thing. From the user perspective the form is something that happened on the previous page. When clicking back and forwards the message it currently gives is great. From that perspective it works the way it should. But the expectations when reloading one page do not include another page to submit data at the same time. (I'm thinking of redial on a phone) New users can not be expected to use the go button in stead of reload when they want to reload. Developers can use the history button or write code to post test data. Alternatively (half joking) the icon of the repost button can change into an envelope and the go button can change into a reload button when post data was send. Another approach: normally load the url into the browser then show the info bar at the top of the page "This page previously submitted a form, would you like to send it again?"
I agree with Jesse's 2006 comment 3. WONTFIX. Adding UI to do this would be edgecasy, and adds even more confusion to the mess that is POSTDATA. If this is really useful for developers, it should be implemented as an addon. [Unsurprisingly, a brief search on AMO indicates no such addon exists. Which indicates this isn't really highly desired functionality. But even if that's a bad conclusion, and addon is _still_ the right route for this.]
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Comment 3 was wrong, at least in the past. There wasn't always a redirect. But I suppose that now blogs have been fixed to avoid the reload problem.
Seriously? This bug hasn't been fixed on 8 years?!?!?! Still getting the annoying "Reload page" syndrome on backing to a page with a POST form. What happens with all the contents? Is it erased without reason? When I click back, I want to return to the page I previously was on. Not a "Reload page"-outblanked page. Today I wrote a message, when I clicked preview the server responded that my token has expired. Well, I thought, I go back and fetch my text, then I open a new form and paste the text. But guess what happened when I clicked on the back button. "Reload page" syndrome! Reloading the page gave me of course a new token expired error instead of the message. I lost the text because of this. On backing, the browser should NOT reload the page. It should NOT open the page as clicking on "Go". It SHOULD view the past page without change. If I want to reload the page, the decision is up to me, not the browser. Parallel to the reality: Do you want to use a type of paper that autoblanks when you start writing on the next paper? I would not. I rather choose by myself what I want to do with that paper.
Oigyo, you're looking for bug 261312 or bug 567365 (depending on what headers your favorite site sends).
Summary: Reload a page without resubmitting POSTDATA → "Reload" a page without resubmitting POSTDATA (load the same URL using GET)
You need to log in before you can comment on or make changes to this bug.