From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 BuildID: 2002061108 A message appears "Page contains POST DATA... etc" while browsing inside yahoo.com mail system and that message is modal and annoying. It will be better if there will be an option to disable that message, at all or for some domains. Reproducible: Always Steps to Reproduce: 1.Go to www.yahoo.com and register in it 2.look to your mail box and try to get back and forth there 3.You'll see that annoying message Actual Results: Modal message on screen: "Page contains POST data..." with option "cancel" and "proceed" Expected Results: No modal message if that "Page contains POST data" messages disabled, or no modal message at all.

*** This bug has been marked as a duplicate of 112848 ***

Bug 112848 is about rephrasing the dialog message, this bug is about removing it alltogether. Suggesting WONTFIX, but it's definitely not a duplicate.

->new

uid is being phased out.

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

Rewrite summary to better describe the issue of the bug.

I spent a bit of time sending mail to and from yahoo yesterday in both Mozilla 1.4 and 1.7 in winxp and didn't see this issue at all. Is this fixed?

What is supposed to happen if the POSTDATA alerts are disabled? Would you get to go back to the old page, even though it's supposed to have expired? I would like this very much.

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

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

This bug occurs when using buzilla (tested 2.19.1+ and 2.16.6). Steps to Reproduce: 1. Be logged out of Bugzilla 2. Go to the search page. https://bugzilla.mozilla.org/query.cgi 3. Enter a bug number & enter 4. Scroll to bottom of bug and Log In. (Takes you back to search page) 5. Enter the bug number again and enter 6. Click the back button. 7. Confirm appears: The page you are trying to view contains POSTDATA that has expired, etc. 8a. Cancel leaves you at current page. 8b. OK takes you back to the bug search page with all fields on the form cleared. Neither 8a or 8b is what you would get if you clicked the back button at step 5. NB: This ONLY occurs if you are browsing an SSL enabled site, testing on our 2.16.6 version of bugzilla that is available internally on HTTP gives no problem with the same steps, but exhibits the bug if using HTTPS. Also, this should not require an 'option' imho, it should not occur in the situations it does occur. Certainly, if it doesn't happen on HTTP then it shouldn't happen on HTTPS, the suspicion being that an assumption is being made about all forms on HTTPS triggering the warning when it shouldn't.

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

I'm developing a dynamic page using portal. This is for an intranet purpose and I get this message when i use more than one portlet in the same page. I need to disable it. Thanks

Uhm, how do other browser handle this situation?

What in my opinion should be the option here: if the page has expired and you don't want to reload it, show the expired one from the cache. At times it's very handy.( it's opera's behaviour btw ) If I go back, it's because I *don't* want to reload the page, just check what was on the page again, which can be a search result, or database content in phpMyAdmin. And I'd definitely like to see the old content. Reloading it not just takes extra time (sometimes a lot) it also erases the old content. :-(

I would just like two check boxes for "Do not show this warning again" And four buttons One with the option "Always allow this site to reload post data" (Which is what I want with the Portal site I am using with my company) One with the option "Never allow this site to reload post data" (Which could be needed in some cases) One with the option "OK, ask me next time" One with the option "No, ask me next time"

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

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

What Comment #12 said. This is a brower issue, not a Yahoo problem. Apologies for filing the duplicate; this one didn't turn up in my search.

This should be WONTFIX. Reposting POSTDATA could result in a credit card being charged twice, stuff getting deleted or inserted twice in PhpMyAdmin, an email being sent twice, and lots of other bad stuff. Not reposting POSTDATA could result in seeing an ugly or useless page with no clue what the problem is. Search utilities should use GET instead of POST to avoid this issue.

this postdata confirmnation screen is a right pain. needs to have a way to disable (or re-enable) it if desired.

I also agree that this should be WONTFIX. Having it can be annoying, not having it could be a disaster if the wrong thing is resubmitted. If it *is* able to be turned off, it should be only for the current session and specific Web site visited. There should never be any way of turning this off globally.

There should be a way to go back to a cached previous page and have it displayed exactly as it was, without resubmitting form data and potentially changing state on the server. The information is there, could we just have some way of displaying it?

Yes, there seems to be some disagreeement or misunderstanding about what the fix for this issue should be. I voted for this bug because I want to be able to go back to a page as it was displayed before, without re-posting any data.

(In reply to comment #20) > This should be WONTFIX. Disagree. > Reposting POSTDATA could result in a credit card being charged twice, stuff > getting deleted or inserted twice in PhpMyAdmin, an email being sent twice, > and lots of other bad stuff. Yes, certainly. And I agree that "always repost POSTDATA" should not be the default, and that the config should be buried somewhere generally accessed only by those users advanced enough to know exactly what they're doing and why. Not all users need handholding, spoonfeeding and nursemaiding during our browsing experience. For those of us who are thoughtful and experienced enough to know what we're doing, the POSTDATA warning is a continual annoyance and hindrance. > Not reposting POSTDATA could result in seeing an ugly or useless page with no > clue what the problem is. Which is why the clueless would not be using this config. > Search utilities should use GET instead of POST to avoid this issue. Perhaps, but that's a different topic for a different thread. The issue exists and ought to be fixed.

(In reply to comment #22) > this should be WONTFIX. Having it can be annoying, not > having it could be a disaster if the wrong thing is resubmitted. If it *is* > able to be turned off, it should be only for the current session and specific > Web site visited. There should never be any way of turning this off globally. I repeat myself: Not every user needs nursemaiding and handholding and spoonfeeding. Consider: It would be a disaster if my mother were to try to drive my car, because she doesn't understand how the gearshift works and she could easily cause a serious crash. Does that mean I shouldn't be allowed to have my car, because she couldn't drive it safely? Of course not. For her and the millions like her, there are nice, foolproof automatics with standardized controls. The same principle applies here: Certainly have the default configuration be the safest one, but put something in about:config that gives power users the ability to get rid of the annoyance. And that ability *should* be global; a per-session option would be half-baked and no less an annoyance.

I repeat myself: For me, the reposting issue is irrelevant. I just want to go back and look at the page I was looking at 5 seconds ago. I don't want to repost anything, I just want to see that page again. I don't even care if it expired from the cache. Maybe what we (I) need is a way to override cache expiration.

> I just want to go back and look at the page I was looking at 5 seconds ago. So does the person who walks up to the computer you were using right after you log off from your bank site. There's a reason we expire some things from cache in ways that make them inaccessible from session history, you know. It's not just because we want to fuck over our users. ;) We'd be happy to do something here once someone proposes an approach that: 1) Does not repost the data. 2) Does not show the old page. 3) Allows reposting the data if the user so desires. (basically sounds like an error page to me, and I'm _sure_ we have bugs on making this an error page).

When I posted my DUP of this bug, it was because I was getting harassed by eBay. Do a search, click on a search result, get prompted to re-submit post data. Do that for a couple hundred search results and you'll be banging your head against the desk for sure. Neither IE nor Opera have this problem, they just re-display the results. I don't know how they made their solution smart enough to avoid it, but for me, that would be the goal. An error message doesn't fix the problem either, because it just makes you re-search or refresh every time. Go ahead and try something like an ebay search in another browser, they've worked around it.

If it doesn't show the old page, there's no point. This whole thing comes about becuase the system doesn't trust me to know what I'm doing when I press the Back button.

Cyber Dog, I can't reproduce your eBay search issues. No matter what I do with eBay searches, I do NOT get the dialog this bug is about. If you can still reproduce your problem on eBay in a current Gecko, please file a new bug and cc me on it. Steve, it's not that we don't trust you, it's that we don't know that you are actually you and not some other guy using the same computer at the library 5 minutes later. Not only do we not know that, but neither do the bank sites that typically want pages to expire from history immediately. They way they see it, it's better to err on the site of protecting their customers in this case.

My particular bug was rather ancient and may very well have been resolved separately. I was moreso trying to give an example of how the proposed solution might not work as well as intended.

My point was that your claim that other browsers handle this better is based on claims about our behavior on eBay that are not true. I _would_ be interested in what IE and Opera do on sites where a no-store page comes back as a response to a POST request and then the user tries to go back to it.

Cnnt you just make something to recognize a financial transaction to have the post data thing, and not for anything else? Like key words for financial to turn it on. I dont do any financial stuff on the computer, so this is really irritaitin. Not to mention, I only can get slow dialup, and the reloading is very time consuming. I go on dating sites and one in particular, if I go back after 1 second on one that I am not interested in, I get this post data ****. It is very time consuming to reload some pages that have a lot of pics and graphics. Can you at least make some check box to be able to turn it off forever, for individual sites? This thing is almost irritating enough to make me go back to using ie. I agree with the previous posting like the car thing. Should everyone not be allowed to drive because someone does not know how to. That sounds like a solution by the federal government! Make the post data thing only pop on when in some financial transaction.

2007 is started, and this problem is not solved yet... I hope during this year You can do it. I have chosen a mouse with lateral keys to move easily back when surfing. I play a lot of browser (note: browser...) games, where we must surf very often back to change and modify data without restarting from beginning... This POST DATA bug (not a bug You say? A choice? Not a customer choice at all!) is very irritaitin like all people tell You in this forum. And I'm considering like Rick to go back to IE or to pass to Opera. Note that I have a lot of friends really 'nervous' due this 160144 bug, but no one have time to write it here. Make optional that choice, plz! There are a lot more of surf conditions where the POST DATA advice is annoying like a POP UP, than the restrict number of cases where it is useful. And in any case: let we choice it, don't impose it to us! Tnx.

If someone can propose a better way of handling the use cases this is addressing, please do so. And no, "guess whether the transaction in question is a financial one" is not the answer -- the cost of guessing wrong is too great (literally, in dollars). Scrigno, are the games in question https: or http:?

Why cant you understand people like me NEVER use my computer for financial. It cant rob me, when it dont have ANY money program NOR ANY credit card info in it! I dont have any Quick Books or anything dealing with my bank account.

And you never buy anything on Amazon or any other on-line merchant? That's fine, but you're in a tiny tiny minority. If you feel that this minority needs to be catered to, the source is freely available and you can change it to suit your needs.

When I buy on any of those, I send a postal money order, or a personal check. I wish I knew how to change the source. I don't know how to write programming "TINY MINORITY" you say. Everyone of my friends are irritated by this problem, and some have switched FROM Mozilla because of this very problem..I dont know anyone that likes it. I LOVE most about Mozilla, but this PROBLEM is almost driving me to Opera to keep from the irritation of it. I think if you actually had a pole of ALL the users, you would find out I am not in the "VERY VERY SMALL MINORITY", but actually, in a much larger group

Workaround (until an option is installed, may that happy day soon arrive): When leaving a page one suspects one might wish to return to, open the new page in a new tab or new window. It isn't /much/ of a workarbound, but it will work.

Interesting this is still going on. Two years and I'm still using opera because it can do it. Yes, it's working, and no I did not get robbed because I can go back and have the page displayed as it was. I do use a good number of online financial sites too. Opera's solution is a perfectly working one. There's no need to invent the wheel again. There are certain pages which must refresh indeed, but at least the rest is working fine. Ah, and and going back to pages with 'password' type input elements; they are never remembered. The rest is filled ok.

arrrghhh! the whole train of response here by the bug bureaucracy shows an arrogant lack of concern for users opinions. i find it really irritating when someone condescends to tell me what is best for me. i'd rather have an informed choice myself; even if i make a bad decision, it's mine. would someone with a little flexibility please fix the d@mn thing, give us a choice. i'd even settle for the default to be as before as long as those who want to change it have the freedom to do so. if there are real technical, political, or financial reasons why it can't be done - not excuses, let us know why, don't feed us the condescending bovine coprolithia. i suspect as opera and other browsers seem to have no problem (see comment #41 & others) it's status-quo is really just due to sheer laziness, beureaucratic inertia, and more inflexible condescending party-line toeing. regards, another little person, a 'tiny minority' of one more who is speaking for the silent majority who want this fixed.

> > Scrigno, are the games in question https: or http:? > http If I can, I post the link, it is: http://www.travian.com/ But that's only an example: every day I damn that hated "POSTDATA POP UP" several times, in most cases and in most sites, Boris!

Another case right now! To write this message in english I consult an online dictionary, (I am Italian) I insert a word to translate it, and if I want to go back to change a letter, the hateful "POSTDATA POP UP" force me to click "OK" every time...and than I must rewrite the entire word, and not changing for example only one letter... But I can even accept that when I'm going back to a previous page, I lose the data entered before in a form, but plz spare me to click more and more times a day, continually, "OK", and "OK" again, and one more time "OK"! It ask me always to say "OK", OK", "OK"...and every time recharging the page...! ARRGGHHH!!! >:( To go back in a page that includes a form to insert data, is one of the most common actions to do surfing! Plz avoid us this recurring "torture". FIREFOX (and his..."family members") is the best browser due multiple reasons, but in this case it is absolutely the worse. Really, Boris, try to do a poll and verify one more time which is the most diffuse opinion... And finally, Opera and IE don't have this..."great safe fixed protection"... but not as far as I know those programmers are guilty of some financial crack or they are arrested by the police...! ;-)

It seems the handling of POST requests in Firefox is not really thought out too well (I am not saying that this is handled better in other browsers, indeed I do not know and I would be interested to learn, if anyone actually knows the technical details), so there are several related issues involved here: * should any non-idempotent HTTP request get stored in session history at all? My personal opinion is no. Only idempotent requests should be something you should be able to navigate to, but not POST or DELETE. Neither should non-idempotent requests get re-submitted in any other way (e.g. by the re-load button). * As long as POST requests *are* kept in session history, should a message be shown to warn about re-submission and what text should it contain? My personal opinion is that the only way to keep things safe *if* we actually keep POST data in the history is to show the warning. However, the current message is so technical, that most users will not understand it, or the consequences of clicking either option. This might in fact make users do the wrong thing, simply because they do not understand the message. * Should there be a way for advanced user to influence the behavior of Firefox, either with regard to what gets stored in session history, or with regard to whether or not a warning should be shown? My personal opinion is that this should be solved in a decent way that will work for most users and should be solved by extensions for the remaining few. To sum up: I do not understand why POST requests are kept in history at all. This causes all kinds of trouble not only when navigating back but probably also e.g. when restoring a saved/crashed session. I do not know whether or how well Firefox handles other non-idempotent HTTP requests, but in my opinion, NONE of these should be kept in history. Since this will spark a lot of discussion and will not be fixed quickly, I would urgently suggest to at least fix the message to something more understandably as quickly as possible.

In 41, Steve said when going back it dont have the password saved.(or words to theat effect) I find on mine it does not show it there, but on the site it is stored and still working, as long as I am logged into that site, (or maybe?, the browser is on).

this should be wontfixed. mpt was right, we should make any such warning human readable, but we should not allow the dialog to go away. the only way to make it go away would be to force people to skip that page when they go back. sure we could do that, but i'm pretty sure no one will approve of that. i'm not sure if the repost dialog has been converted into a pretty error page so that you don't get a window modal dialog, if it hasn't that presumably should be fixable too.

(In reply to comment #47) > the only way to make it go away would be to force people to skip that page when > they go back. sure we could do that, but i'm pretty sure no one will approve of > that. > Why? Why should a non-idempotent HTTP request be in the history at all? I do not get it why this problem even exists.

I just went over to Opera and checked a few sites. No problem with it. Also it is at least twice as fast. Also it is rendering perfect images on the screen. It reports that it is IE 6, so the sites send good html strings. This bad string problem really is irritation. I just went on the local TV station home page, for KTVI and it kept jumping around and then prints one line over another. I am really getting tired of the bad rendering because we cant make it report as IE. There are different strings sent to different browsers. If showing as IE, it renders perfect. Right now, this is the worst any browser has worked since I got on the internet in January 98 I love a lot of features about Mozilla, but it is getting so bad I am not going to be able to put up with this degradation much more. It keeps getting worse, not better.

Scrigno, what's the online dictionary you were using? I can see allowing this to be disabled for non-https sites, for sure.

The last few comments show a pretty complete lack of understanding of what this bug is about and are making it less and less likely that anyone will ever read enough of this bug to fix it. Just to summarize the actual issue for all the people who want to drive-by comment: If a page that is the result of a POST request has been expired from the cache (usually this only happens because the site requested that it be no-store for security reasons) and the user navigates to it through session history, what should happen? Current behavior is to ask the user whether to repeat the request; this is suboptimal because most users have no clue what to do with that question. So we need a better approach. Just silently repeating the request is also suboptimal, since the circumstances when this dialog appears typically involve the site explicitly telling the browser that the page in question contains sensitive information. Of course it could be that some sites lie about this. ;) So the real question, again, is what the right solution is. Perhaps a per-site preference of some sort? ccing some more UI and app folks; this is really not a technical decision so much as a UI one.

>> this should be wontfixed.... This should be WILLfix, for all the reasons stated by those who object to this irritating, browser-specific "feature." Some suggestions: (1) Make the dialog ESC-able (if it isn't already; I detest being forced to use the mouse); (2) Just don't re-send the post-data. Why should that be so difficult to do!? It would make the warning moot. (3) Offer a pref to disable which would result in a reload of the page without data!

> (2) Just don't re-send the post-data That's easy to do, for sure. Makes the history navigation pretty useless in all the use cases described here, though (would show some sort of weird error page instead of the actual page the user wants).

(In reply to comment #53) >would show some sort of weird error page instead of the actual page the user wants Like Internet Explorer does, you mean? Webpage has expired Most likely cause: * The local copy of this webpage is out of date, and the website requires that you download it again. What you can try: * Click on the Refresh button on the toolbar to reload the page. After refreshing, you might need to navigate to the specific webpage again, or re-enter information. + More information If you continue to have this problem, try the following: 1. In Internet Explorer, click Tools, click Internet Options, and then click the Advanced tab. 2. Scroll down and uncheck the "Do not save encrypted pages to disk" option in the Security settings.

No, that would be an internally-generated error page as a replacement for this dialog. I'd be perfectly happy with that. What Steve was suggesting would result in a server-generated error page. Sounds like we should just do what IE does here.

It has been explained that the purpose of the current behavior is to protect against situations like one user using the Back button to go back to another user's online banking page and doing evil things. It has also been pointed out that if this behavior is inconvenient, you can work around it by planning ahead and opening links in new tabs or windows. (How would I know when to do this?) It seems to me that the existence of such a simple workaround weakens the protection argument, and so I am still in favor of letting the user decide whether these pages should expire.

> It has been explained that the purpose of the current behavior is to protect > against situations like one user using the Back button to go back to another > user's online banking page and doing evil things. No, that's not its purpose. I'm sorry you were given this false impression. Its purpose is to not automatically perform banking or purchase transactions twice while at the same time allowing users the option of repeating the POST action if they are sure they want to. It's not a very good solution; that's what this bug is about. > you can work around it by planning ahead and opening links in new tabs or > windows. Actually, not really. Certainly you can't do a POST in a new window. You can open things in new windows from links, then do a POST in that window and then never close that window, but then there's no going back involved -- the other user just walks up to the computer and looks at the window. > so I am still in favor of letting the user decide whether these pages should > expire. I can't see typical users deciding for every single page they visit when it should expire from cache. In any case, this part is well-standardized -- we expire the page when its expiration time comes. This time is communicated to us by the server.

(In reply to comment #53) > > (2) Just don't re-send the post-data > > That's easy to do, for sure. Makes the history navigation pretty useless in > all the use cases described here, though (would show some sort of weird error > page instead of the actual page the user wants). > Not sending the post-data was exactly what I suggested: Again - why should something that CHANGES data on the server (like a HTTP POST or DELETE request) get stored in the history (or some other navigation list) at all? What use cases exactly break here when the user could go back to the page *before* the post request is submitted, i.e. the filled out form instead. Being there, it will be immediately obvious how the form can be re-submitted -- or not. If there is a chain of post requests ALL of them should be skipped in the history because all of them (potentially) change data on the server. HTTP makes a clear distinction between requests that just retrieve information, potentially with paramters in the URL (GET) and requests that change data on the server (POST, DELETE). I still do not see why the latter should be part of the history at all (except those cases where web designers abuse POST requests for simple idempotent parametrized retrieval)

(In reply to comment #58) > HTTP makes a clear distinction between requests that just retrieve information, > potentially with paramters in the URL (GET) and requests that change data on > the server (POST, DELETE). I still do not see why the latter should be part of > the history at all (except those cases where web designers abuse POST requests > for simple idempotent parametrized retrieval) > You're right of course. It'd be indeed so if people would learn web devlopment in the school and obey it - or if this behaviour would be forced in any way. But as it is, there are plenty of pages which don't change data on post, or do change data on get reqest. In my opinion, unless the no-caching is forced, (or it's https) the cached page could be displayed, and if they really want to re-send it, they can simply do that by refreshing the page. The "back" is pretty much "back in history" in this case. And I think that's the real use of it too. What could be in setting (select one); - show all 'post' requested pages from cache (https as well) Security warning! - show non-https post req from cache - show non-https post req from cache while observing the set page expiry (new default?) - use no cache for post req - reload every the time without exception on post req - let me chose every time (old default) - (maybe one more; skip post-requested pages in cache) If someone refreshes manually on the cached post page, that'd re-send the request. And everyone would be happy. It'd result in an extremely flexible and usable behaviour for all of us :)

> why should something that CHANGES data on the server (like a HTTP POST or > DELETE request) get stored in the history (or some other navigation list) at > all? Because in most cases we can show the (old) result page without actually redoing the HTTP request at all; the only exception is if the site explicitly requested that the page be no-store. The issue of HTTP cache versus session history (and the fact that they're not the same thing) has been discussed to death over the years; let's not start that discussion here. Comment 59 is way off in terms of what the current behavior is. The actual behavior is "show all session history navigation from cache unless the site is using no-store, in which case the data is not stored anywhere on the machine, since the site asked for it not to be stored. In the no-store case, just redo GET and prompt for POST". Comment 59 is also way off in terms of its claims that the UI folks will be happy with adding an entire pref panel's worth of prefs for this. I can guarantee that they won't be. ;) Again, it seems to me that people are trying to solve other issues than what this bug is filed on. If so, please don't waste the e-mail bandwidth of this bug with your comments. What this bug needs is a UI spec from someone who can actually design UI, not advocacy or long lists of possible pref options.

I can see now why so many are removing Mozilla. I have had it myself. I am going to switch to Opera, which is MUCH faster and does not have the post data ****. Today while surfing on dating sites, I think I had to click it off almost 100 times. For anyone to think this is good, he must either be on dope or dog food Rick Harvey

(In reply to comment #60) > > why should something that CHANGES data on the server (like a HTTP POST or > > DELETE request) get stored in the history (or some other navigation list) at > > all? > > Because in most cases we can show the (old) result page without actually > redoing the HTTP request at all; the only exception is if the site explicitly > requested that the page be no-store. Well, the real mess is here in the HTTP specification and the way how people (ab)use it, but still: when the site requests that a page that is the result of a POST request is no-store, why even attempt to re-show it? When would that ever be save, even assuming that the user understands the message? I'd still argue that at least in these cases, that request should not become part of the (visible) history. If the page is in the cache, at first look, there seems to be no harm to just re-show it, but here also, there is a logical inconsistency. The page *before* that result page will contain a button that was pressed to obtain the result. Should the user expect to get the same result by going there and pressing the button? If that request actually changes things on the server, the result might look identical, but the things might still be very different. So, personally, I think that even then we should not store the result page in history and instead only either let the user navigate to the page before that result page and explicitly re-submit the POST or let him go forward again to the page following the result page (i.e. the forward button will NOT re-submit the post, like in general, nothing but the actual web page button or javascript should be able to re-submit the post). As long as POST requests are part of the history, I think we should change the warning message to something reasonable ASAP -- the current version is embarrassingly techie. There is no way I can see Firefox to support silent re-submission of POST requests. Maybe somebody will fulfill that, uhm, interesting wish in an extension.

(In reply to comment #60) > Comment 59 is also way off in terms of its claims that the UI folks will be > happy with adding an entire pref panel's worth of prefs for this. I can > guarantee that they won't be. ;) sorry mate you might have mis-understood or I wasn't clear. The provided options would fit into one single pulldown, they don't take up any extra space. I'm sorry wasting your email bandwidth, I'll simply quit from here, as I seem to be a trouble with my 3 post around with you presumably on a 9K modem. I'll instead use my Opera as I did in the past years, it's actually getting better and better :D good luck and good bye

(In reply to comment #50) > Scrigno, what's the online dictionary you were using? > > I can see allowing this to be disabled for non-https sites, for sure. > This one: http://www.garzantilinguistica.it/index.html

I cannot believe that this bug still exists. READ MY LIPS DEVELOPERS: This bug WILL be the end of Firefox if you don't stop and think about what you are doing. After all these years and all these versions of Firefox, I still have to uninstall it and go back to other browsers because you seem to lack the common sense to do what needs to be done on this issue. NO USER CAN MAKE USE OF FIREFOX WITH THIS BUG, IT COMPLETELY RUINS THE BROWSING EXPERIENCE. The solution is so simple that it's comical, that is why all other browsers have been able to solve this problem so easily. When a user clicks the back button, they just want to view the page that they were looking at before, THEY DO NOT EVER WANT TO RESUBMIT A FORM. Resubmitting a form is not the purpose of the back button, and it is idiotic to think that it is. The RELOAD button's job is to resubmit the form, not the BACK button, think about it. If a user presses BACK and then RELOAD, then it is appropriate to display the POSTDATA message (although the wording of the message needs to be made less-techie and more common sense, such as: Pressing "Reload" on this page will re-send a form that you have completed. If you are on a financial transaction page, this could result in a duplicate transaction. Are you sure you want to reload this page? Yes / NO.") Just display the page as it was before, without resubmitting a form, and the problem will be forever solved and you will get no complaints, it is that easy. Until you do this simple thing, Firefox will remain a second rate browser. I apologize for any harsh language, and as a developer myself I know how difficult it can be to sort out user interface issues when you have been staring at the same piece of software for so long, but after this many years, someone MUST wake up and take notice of this issue.

> Just display the page as it was before, without resubmitting a form If we have that data and if the site did not explicitly request that we not do that that IS what we do. Did you read comment 51 like the status whiteboard says you should? This bug is all about what should happen when we CAN'T show the data that was already there. Now please stop spamming this bug. Everyone agrees that the current behavior sucks. The only question is how to make it better, and the answer to _that_ seems to be an error page. Which means what's needed now is a UI spec for this error page, and then someone to do the implementation work. However if people keep adding irrelevant comments there's no way for the UI design folks to notice the request for their input.

for those who cannot wait any longer for an official patch, have a look at the 'tab mix plus 0.3.5.2' add-on as it appears to address part of the postdata problem on it's 'sessions' property window under 'advanced'

Wayne, that preference is just a preference for when Tab Mix Plus should save the data in question in its crash-recovery info. It has no effect on actual browsing, unless you crash.

ah, well wishfull thinking i guess. thanks for the info.

I think a big part of the problem is that having a page "expire" at all is often (if not always, for some users) contrary to user expectations. To many people, including myself, returning to a previous page using the Back button should work the same as by switching tabs or windows. Why should this not be true? If the server has given an expiration date, why does this override user expectations?

David, back/forward in history _does_ ignore the server-provided expiration date. The thing that overrides user expectation is when the server sends the page as no-store. That is, it says that the data on the page is so sensitive that it should not even be stored on disk on the local machine at all, and stored in memory as little as humanly possible. Secure sites often send data as no-store precisely so that you _can't_ go back in history. That way if you're at a public terminal (library, etc) and access your bank account and then log out, another user can't just go back to view your data. Allowing going back to such data is not an option; the moment we do it, banks start blacklisting our UA (it's been tried before, since everyone agrees that ideally users should be able to go back to everything they saw; the problem is preventing them from going back to things other people saw).

I came to this bug because I encounter this error message constantly on some sites and it drives me crazy. I read comment 51 and I looked up some stuff, like "post request", but as a non-programmer, I do not know if I am understanding everything correctly. Perhaps the summary could be dumbed down a shade. Also, in my research on this subject, I did not find anything about security, just trying to prevent an action that actually changes something, like sending an email or making a purchase, from occurring twice. Thanks

This bug contains quite alot of different opinions, but I think one user summarized it quite well: "Not all users need handholding, spoonfeeding and nursemaiding during our browsing experience." Please add a way of disabling this message in about:config for advanced users. It is clearly needed and wanted.

IMHO that popup is needed, at least to avoid unintentionally re-doing a purchase by reloading-from-server a page which was sent in answer to a filled-in purchase order. OTOH, if I sent a form while my line was disconnected (without my knowing that it was), and I got the XUL error page, then if I click "Try again" after reconnecting, of course I want to re-send the form data, since it never reached the server the first time. So "always resend" and "never resend" are both "suboptimal" -- this is an understatement. The way I see it, the problem is that nontech users might not get the message. So I guess the solution is to send the same popup but with a message more understandable to "naïve" users. I suggest the following: ------------------------------------------------------------------------- The page you are trying to view is the result of filling in a form. Are you sure you want to send that form again? [[ Cancel ]] [ _R_esend ] -------------------------------------------------------------------------

Firefox 2.0.0.2 os out.. With POSTDATA screen of course.. Agrrrr

(In reply to comment #75) > Firefox 2.0.0.2 os out.. With POSTDATA screen of course.. > > Agrrrr > Strange innit? The only explanation I can think of is the bug didn't get fixed by itself.

On the opera site i read http://www.opera.com/support/search/view/82/ Note that cache expiration is not checked when going back and forwards in the window history. It is only checked when you click a link. See RFC 2616, section 13.13. So looking there http://www.ietf.org/rfc/rfc2616.txt i find: 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. This statement is very clear, and is motivated well further in the RFC. I do understand that the "no-store" header is very important for security, but storing a page in memory, in order to be able to redisplay it in the same browser session, sounds acceptable to me. The least you may demand from a user on a public computer is that he closes his browser when he leaves, right? So, say we agree on that, which are the problems in opera's solution, that firefox developers dont agree on?

Hi, Looks like this is bugging a lot of people. I get this popup very frequently even when the page has no forms at all. Of course comment #51 could have to do with it, but it's getting worse so that I can hardly surf at all. Check out http://www.myvoipprovider.com/index.php?option=com_result And click on one of the voip companies, it goes to a page, and if you hit the back button, up pops that warning. Now I know that I made a selection of country and what have you, but I often have this popup with just plain pages with nothing at all entered, and for that matter no place to enter anything---no forms or boxes to check or anything. And also I get that popup if the connection times out and I hit back again. I have surfed a ton for a couple years now, and I never had near this amount of problems until recently. I agree with one poster who said let us decide if we want to chance something, since there are at least a few of us that are capable of paying attention and deciding things on our own. I for one would never hit "back" if I already put in my credit card. And if people are that clueless, well then warn them, but please if there's a way around this, let us know. Thanks

As much as I doubt anyone will care, here's what I would do: When viewing a page from the history, e.g. by pressing the "Back" button, I'll say that page is "within the history mechanism" or "a history page". Of course, using the back button invokes the history mechanism. While within the history mechanism, never interact with a server. Hovering over a link or button should cause the status bar to indicate weather that link or button will leave the history mechanism. Have some visible indication of being within the history mechanism; perhaps a different background in the address bar & a right-hand icon like the lock for secure pages (and show both when it's a secured page in the history). There should also be an information bar with the page retrieval time, a reload button, a link or button which brings up the relevant section of the help file, and a control to turn it off. When showing a history page which is a result of a request which is expected to change data on the server, show an information bar with a button to resubmit the request, and a link or button which brings up the relevant section of the help file (which would have information about mis-use of those methods by some sites). If the content of a history page is not stored in the cache, show an error page with a heading like "Page content missing from cache", something about why (expired, cache size filled, server said not to cache it), and a link or button that would bring up the relevant section of the help file. If this history page is not the result of a request which is expected to change data on the server, then this error page should also have a reload button. If the user follows a link from a history page, and the destination of that link is both in the history and in the cache, stay within the history mechanism. If the user follows any other link, leave the history mechanism. If the user presses a button on a history page, and the button has previously been pressed, ask weather to resubmit. The first time, or on the second consecutive press of the same button, it should be a dialog box, otherwise it should be an information bar. The choices should be "go to page in history", "resubmit request", and some control of how the notice appears. A configuration option to automatically go to history page (which has it's own info bar) would be good, but the option to automatically resubmit should not be available. If the user presses a button on a history page which has not previously been pressed, leave the history mechanism. (Some warning that this can create an invalid request might be appropriate, but I can't think of a good way to decide when to do that unless the browser knows something about what the server is doing. This might become possible, but I'm not in a hurry.) Any time the user resubmits or reloads, the result is not within the history mechanism, and subsequent actions within the page do not invoke the history mechanism. When there is an error loading a page from a server (not from the history) which is the result of a request which is expected to change data on the server, the error page should not show a "try again" button, but should show an info bar similar to the one for historical responses. For sites which abuse the protocol, have a context-menu option on buttons to press the button but not expect the request to change data on the server (you might call this an "impotent POST"). (If the browser can learn from this sort of action (more than just this would be necessary, it might be possible to start making useful predictions which would make it possible to have meaningful warnings in situations like pressing a previously unpressed button on a page in the history mechanism potentially making an invalid request. But I'm not in a hurry.) Have an option (off by default) to do additional caching solely for the history mechanism, ignoring sever-provided caching instructions. (Maybe have an additional separate option to include no-cache pages.) Have an option to make loading a page from the history menu or sidebar invoke the history mechanism, and not reload the page from the server. Having that on by default might be alittle to far from user expectations, but with the info bar on by default it might be ok. Story the link path in the history, and provide a treeview interface of recent browsing. (I'd prefer it to be drawn more like a family tree than a directory tree, but I have concerns about that.) Opening pages from the treeview invokes the history mechanism. If the browser becomes able to automatically decide that a button is "impotent" (even by explicit setting from the user), hovering over those buttons should cause the status bar to indicate that, and those buttons should have a context-menu item to press them and consider them "potent". So that's how I'd do it. But maybe that's just me.

This was mostly fixed in bug 112848... is there anything left to do here?

Mostly fixed? How do you "Mostly Fix" something? Is that like "I had the doctor Mostly Fix my broken leg today?" This has been and IS a continual annoyance and it seems like the only people who insist on maintaining it are programmers with a god complex intent on forcing the browser users to live with it. "You WILL accept this!" is not the way to sell a product to the world. IBM found this out with their hardware. It's still occurring on blogs, Yahoo mail and a dozen other websites that I visit. Like most other complainants I don't use FF to make monetary transfers 99% of the time. During that other 1% I am conscious of the minimal risk of someone tacking an expensive device on to find my personal data. Matter of fact I just got a letter from Gorilla.com informing me that all of their data has been compromised by pirates. Your annoying firefox bug didn't help prevent that did it? Face it. 99% of Firefox users DO NOT want this annoying delay/misdirection when browsing the internet. It happens in blogs and Yahoo groups, searches and on line games which is where most people spend their time. Mozilla software engineers refuse to repair it based on their twisted principles. Good for you. **** off the people you want to use your product with lame excuses. Where's that going to lead with Mozilla browsers? One main reason for using FF is to lose a pile of MS **** and controls. Frankly, IE is a lot less aggravating than this POSTDATA error and I'm starting to use IE a lot more - against my choice. I DON'T like MS products and FF was a godsend up to the point where you forced users to accept this problem (even with the giant memory holes). Notice that people are losing interest in this thread? Been watching your market share? It's not because you "won" the argument, it's because they're moving on to other browsers. Firefox has been out ahead with new innovations like tabbed browsing. Very easy to jump on the bandwagon for all the add-ons, but MS is pursuing. Don't let them win. Fix this thing right. People DO have a right to decide how they want to use it. Good luck.

Nice rant. What is your proposed solution given the constraints the programmers have to work under - constraints which are imposed by the RFC's, not by Mozilla?

Sorry for the second post, but saying "just reload the page and move on" does NOT solve the problem. It just ignores it. THAT is the solution that needs to be suggested. Not whitewashing it.

CASE FOR MAKING A CHANGE AND A PROPOSED SOLUTION: Scenario: I am working on a web-based application that opens "child" browser windows for the purpose of performing add/update/delete operations. When a record is added, updated or deleted via the child window, window.opener.location.reload() is called from the child window (which then closes). The purpose of this call is to refresh the search results in the parent window (e.g., if a record was deleted, it will no longer appear in the search results in parent window). This _would_ work, but for the modal "confirm" dialog. What happens is that the child window cannot close because the modal dialog prevents the reload from being completed. Because the child window is "modal" a contention between parent and child windows occurs. To explain, the parent window checks every .5 seconds for the child window, and if found, sets focus on the child window (thus forcing user to deal with the child window or close it). PROPOSED SOLUTION: Rather than disabled the reload/confirm dialog entirely, do as follows. 1) Detect that the reload was called by a script and reload the page without displaying the reload/confirm dialog. 2) Provide a new option (in Advanced JavaScript Settings) for specifying whether or not to allow this override. This solution is consistent with the other Advanced JavaScript Settings. Web-based solutions have become the de-facto standard for business applications, so it makes good business sense for Mozilla to find acceptable ways to support the use of this web browser for this purpose. Moreover, if Mozilla takes the lead in providing solutions that can be deemed "best-practices", they will lead the industry in this area (rather than our friends in Redmond, who have a less than stellar record in this regard). Sincerely, L. Goodwin

Best practice is to do a redirect after post. Or: as a web developer you can always design your pages correctly and not have the dialog pop up when it shouldn't.

WORKAROUND TO MY PROBLEM (does not clear the reload alert): I found a way to prevent the reload/confirm alert from getting in the way of my child window closing after calling window.opener.location.reload(). The child window calls this function in the parent window. This gives the user has time to OK the alert (and the child window to close) before the parent tries to set focus back to the child window: function doRefresh () { setTimeout('location.reload()', 10); } I would still like a way to suppress the reload/confirm alert when reloading a page from javascript.

You're wasting your time. These "engineers" don't have a clue on how to make this thing work. I've given up being aggravated moving between screens in my newsgroups and switched back to IE. Hated to do it, but at least Microsoft knows how to build a browser. Far as I can see lots of people are moving away from Firefox so you might be better off supporting something that people will be using in the near future. Netscape thought they had the market. So do these guys. We'll see.

(In reply to comment #51) > If a page that is the result of a POST request has been expired from the cache > (usually this only happens because the site requested that it be no-store for > security reasons) and the user navigates to it through session history, what > should happen? Current behavior is to ask the user whether to repeat the > request; this is suboptimal because most users have no clue what to do with > that question. So we need a better approach. From a UI perspective, the dialog box is a terrible sin, but it is a symptom of a deeper problem. The most intuitive interpretation of the 'Back' button is that brings up exactly what you were previously looking it - ie it re-displays the last page exactly as it was previously displayed (from cache). Re-requesting the page at the address previously requested is the root of the problem. Solving that solves the dialog box problem. This way, returning to a page previously displayed would not send any messages to the server (so there would be no danger of submitting duplicates). If the page is marked as 'do not cache', then do not cache it! If a page is not in the cache, or has expired, then the 'Back' button should take you back to the most recently visited page that was/is cached. Then there is no need for the dialog box. > So the real question, again, is what the right solution is. Perhaps a per-site preference of some sort? The average user does not understand client-server messaging, and therefore cannot make an informed choice about how to deal with this dialog box. Besides, modal dialog boxes are a UI sin of the highest order. Web-browsers (like all applications) should behave how most people would expect them to behave whenever possible. Clicking 'Back' and potentially getting a page that differs from the one you expected is confusing and wrong! Its already obvious really, that if you press 'Back' your page is potentially no longer the most up-to-date. However, if the techies insist, a _non modal_ way of communicating that a page may not be the most up to date version possible could be to make the refresh button flash, for example, or put a crossed out clock icon in the address bar. That way everyone else gets a browser that behaves as they expect, but the extra information is there for those who want it.

"...usually this only happens because the site requested that it be no-store for security reasons...." Probably not. In these days where "everyone's a programmer" I suggest it usually happens because the page is coded that way without thinking about it, or even knowing to think about it. There are a number of sites I visit all the time where I am beset with this problem for no discernible reason. WHY should there be a concern about going back to the page that contained my "Friends List"? For my bank, WHY should there be a concern about going back to the page that listed all my checks for 2007 by assigned category (with the category updated to reflect the change I just made on the page forward)? In the first example, the site is just simply coded without thought. In the second it is coded without adequate thought. In neither case is their any security risk entailed by sending the original request again! In the first case I both cases there is no reason why I should not see the page post-update, there is no data going to the server from a form! It is a page request and nothing more.

It occurred to me that a solution to this might not actually be so much in the dialog itself as in the form submission that uses POSTDATA in the first place. If there was a way to present such forms that looked different from the pages that don't use them, the dialog about POSTDATA might actually make more relative sense to the end user. The image that came to my mind is the property sheet handling in Mac OS X, where it comes down from the main window or dialog's titlebar as an attached sheet, floating above it's parent. This precise method wouldn't work with how some of these forms exist in pages, but the concept I believe is correct. Some sort of field color difference, focus ring type behavior, or other tactic could be used to highlight such a form and thus make more obvious that intentionally ephemeral data was being sent. If the form is hidden for some reason, some other notification could be put in place, perhaps like the lock icon or highlight color in the address bar when https is used. You could even add such an icon to all pages with such forms. Once the nature of the page's forms is clearer, the reason you are running into the dialog could be much clearer - and perhaps less effort would need to be spent on wording that dialog. Basically, fix the problem upstream before it occurs.

I want the following behavour (may be switchable by some preference option): to be able to see last page visited as is, as it has been rendered last time I visited it, may be with flag "this page is not current", with NO "POST" operations being done for this page.

I would like all pages in the history to be cached, regardless of what the server says. When I click on the back button I expect the previous page to be displayed as it was without being revalidated - I don't want to see what it should look like now, I want to I want to see what it looked like last time it was displayed - that's why I clicked on "Back". If I want an up to date copy of the page I will click on "Reload". Only then is it reasonable to show the post data warning. From what I remember of the comments above, this seems to be a common expectation.

What I find missing in above discussions is the concept that there might be an actual bug in the code, instead of a difference of opinion on how it should work. For instance, there is somebody who complained that he/she couldn't use ebay without hitting the stupid prompt 100 times, and somebody else couldn't reproduce. The same for somebody using yahoo mail. And I have that same experience with two of my PCs. One of them has it almost always, and the other when visiting the same website, and looking at the same screens and doing the same actions has no popups about postdata. We can't blame the website, we can't blame the postdata philosophy, so what is causing the difference? Could it be as simple as a bug?

The WONTFIX comments above smack of nannyism and presumption that you know better than users of the program and so you, in your wisdom, need to protect them. There are plenty of features on all browsers, hell, on every program, that can be deemed unsafe or unwise or whatever. Its hardly the role of an opensource programmer to decide he knows better than the poor dumb user so he's going to make some features, even something as moronic as a POSTDATA warning, compulsory. Heck, why don't you go whole-hog and disallow clicking on YES so they don't reload postdata by mistake! You never know! One of the advantages and attractive things about an open source program is customization of functionality. Just because some fussbudget thinks the rest of the world is too stupid to handle a feature is no reason to humor them. The entire idea that disabling something so innocuous as a warning box is unthinkable is ridiculous. Get over your own sense of superiority, ok? The vast majority of users want control of virtually all facets of the interface. Stopping ALL warning pop-ups should be an option. Its not hard to code in, I've seen some coders doing it freestyle already. The public wants it, its a valid fix, it should be done.

This is what the warning should contain: __________________________________________________ Confirm: To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier. |Resend| |Cancel| □ Check box to disable this warning in the future(Can be undone in the options menu) __________________________________________________

Why not this way? |Resend| |Show exact last page as it was just displayed from cache (the page will be not up-to date)| |Cancel|

(In reply to comment #22) > I also agree that this should be WONTFIX. Having it can be annoying, not > having it could be a disaster if the wrong thing is resubmitted. If it *is* > able to be turned off, it should be only for the current session and specific > Web site visited. There should never be any way of turning this off globally. is almost dictatorial do not let to the user make thier own the choice. I think if a BUG have 97 replies and 10 duplicates some wrong is hapenning. You can process site by site asking some: --------------------------------------- Resending data to www.site.com can make a new credit card or puchrase again bla bla bla. (resend allways for the site) (resend now) (cancel) --------------------------------------- Equally the POSTDATA is a USELES warning, AND i will tellyou. My browser open 20 tabs simultaneously. and de actual data DON SAY TO WHAT SITE IS THE POST DATA. The result is i press 20 times "ok" and never i will know to what site was. Please consider that if 97 people take the time for registring, search the bug, submit their opinion and WRITE in a non maternal language thereis so many people paining for this BUG.

(In reply to comment #51) > If a page that is the result of a POST request has been expired from the cache > (usually this only happens because the site requested that it be no-store for > security reasons) and the user navigates to it through session history, what > should happen? Current behavior is to ask the user whether to repeat the > request; this is suboptimal because most users have no clue what to do with > that question. So we need a better approach. > So the cache can have a configuration to "keep cached more pages" (note that i dont talk in Mbytes, i am talking in PAGES. I repeat the actual warning is COMPLETELY USELESS. > My browser open 20 tabs simultaneously. and de actual data DON SAY TO WHAT > SITE IS THE POST DATA. The result is i press 20 times "ok" and never i will > know to what site was. Multitab is not the really goal of firefox???

In addition to just about ever blog I frequent, I have the same problem on a site where I have to submit several groups of files on a regular basis, then register each set of them to make sure the get where they're supposed to be. If the submit command fails (and it does from time to time) I have two choices. Either transfer all the files again and then try to register (what Firefox wants me to do) or hit the back button. So I tap the back button and (GLORY BE!) I get the "stupid" screen. So I cancel and nothing. I have to hit back AGAIN and as quickly as possible cancel then hit back another time to get to the previous screen so I can re-submit. Bottom line is I CAN defeat the "stupid" screen so what's the point? It provides NO protection. Just another aggravation for the user. It's sad, but this is what you get for free. Sub standard support and no response. It's obvious the engineers can't figure out how to put in an "off switch" as this complaint has been addressed in every possible perspective since the year *2002*. Face it folks. It's a useless "feature," nobody wants it and they can't figure it out. It's a lost cause. The engineers claim "it's for your safety" whether you need it or not and refuse to fix it. It's supposed to be for credit card secured pages only, but it is applied to every blog and many other applications across the internet where it has NO PURPOSE. That makes it an annoyance. An annoyance is not something that the user will pay attention to. That makes it useless. Firefox exposes the proficiency of their engineers and their customer support by how they manage this one issue. Pathetic.

Okay guys look, I am sure there are lots of controversies regarding this bug, and perhaps the web is so broken that an optimal solution _cannot_ be created. Nonetheless there are ways to make this bug not annoy the $hit out of users. Here is an example: Joe Sixpack is playing Travian, the page reloads using javascript but there comes an ugly dialogue with stuff he doesn't understand. He presses resend and the page works as it should, from now on he always presses this button on this site. Better solution: Provide an "always resend for this site" and "never resend for this site" option so Joe isn't bothered with it too often. Perhaps there could be an "advance button" specifying "always/never send" that expires at the end of the session/day? I think this is a good compromise between unyielding security and the user's comfort. I hope this bug gets attended because it has been annoying as hell to me.

$100 in your paypal account to the first person who can tell me how to fix this annoyance. Ive been watching this page for several years now. I consider this even more irrtating then pop up ads. I expect unscrupulious advertisers to annoy me but when my own browser does this i am furious. I would rather be slapped in the back of the head every five minutes then deal with this annoyance.

You can fix this by complaining to the web page authors, and make them fix their code. It's easily fixable at their end, just use "redirect after post". How about people put energy into that instead of complaining.

(In reply to comment #103) > You can fix this by complaining to the web page authors, and make them fix > their code. It's easily fixable at their end, just use "redirect after post". > How about people put energy into that instead of complaining. First of all you cant "make" people do anything. On second thought thats a good idea,Yeah lets contact every owner of every one of the bilions of web pages on the planet rather then fix the problem. I have a great idea that makes just as much sense. Cars without suspensions would be cheaper to build. So buy a car without a suspension and then focus on making every municipality make every road on planet earth smooth as glass.

FIRST (In reply to comment #103) > You can fix this by complaining to the web page authors, and make them fix > their code. It's easily fixable at their end, just use "redirect after post". > How about people put energy into that instead of complaining. Is the same to say "use opera and dont disturb". If we write here is due we belive into GNU project, and we want add our little of sand to the project. You must ear all GNU detractors saying "nothing better than commercial things". So we try to demostrate the OPENSOURCE can be better. But, is really disapointing read "we dont care your suggestion" in the way of you want to say. SECOND From comment #51 ALL comments agree a PER SITE "silent resend" or "ask to the user" THIRD I demonstrate in comment #98 that the actual warning is USELESS the only use is obfuscate to users. FOUR IS a bug that firefox dont keep into cache as minimum the actualy displayed page. Is normal if i go out of a page and the page have NO-CACHE tag the data must be erased from cache. BUT IF I ARE SEEING THE PAGE MUST be into cache. This must be, you know that the actual seeing page i can: DUPLICATE (and must no resend data), close browser (and re-read the old data). Including the cache leaks is a bug seen with you own eyes. Look that. You buy something or pay something. So i have a NON CACHED page, generally the certificate of pay that must be printed for archive. If i dont print, and close the browser (power loss, or accidental browser close or etc) i can't print after this certificate of pay. WY I must HAVE a blank tab instead MY own data? So of 2 diferents ways the road go to firefox bug. Cache leak, and useles window. Please read this not to fight, simply read as well intentioned discussion.

I still haven't seen anybody attached a patch with their idea. Any developers who follow this, know quite well already that people want this - but it's literally at the bottom of a thousand plus to-do list. As this is not a commercial program, and is entirely volunteer based, this is one of those things that will only get fixed if there's somebody who knows code AND has a personal vested interest in getting this "fixed". So far, that hasn't happened. Any continued "me too" type comments will only make the developers following this annoyed, and have them push this down their to-do list (or cross it off altogether) because of the noise that this is generating. So, either just wait - or find somebody similarly interested in fixing this offline and bring them into this bug so that they can submit a patch for code review.

There is NOTHING more annoying than Bastard Developers From Hell, who think that they possess the "Only True Knowledge" (TM) and that all must abide by it. Changing the behavior from earlier versions without an ability to revert back - and do this by concocting up a silly use case story - is a violation major usability principles. Do any of those developers have idea what kind of a disaster this leads to with multi-tab session restores (or multi-tab start pages) on sites that have nothing to do with their pet use cases? Just basic post data sites that we *want* to resend automatically. You know, the kind of use cases that overwhelm the "I accidentally ordered 10 computers" scenario by about 10 000:1. This has totally destroyed Firefox for me. Have to change browser if this isn't made user selectable. I think all mozilla developers should be forced to take a *basic* course in Usability 101. They would never again make basic blunders like this.

Ok, the last comment was really hard. Please listen to the people. I can help, where i can download the sourcecode?? Regards

This is basically what we are looking for, someone with coding experience who is willing to donate time to fixing an issue. If you want the project assigned to you, look at this page https://developer.mozilla.org/en/Developing_Mozilla Browse the links and check the developer forum or go to irc.mozilla.org. Ask what you need to do to have this project assigned to you and what resources you will need. This project is: Bug 160144 - Replace "PAGE CONTAINS POST DATA" with better UI

I started using Internet Explorer 7 for certain sites. If this goes on, I will have to switch to IE. Site is completely harmless and I need it for my work. Whoever did this ****, should fix the code. I dont believe that IE really has this obvious security loophole, which would made you order 10 laptops instead of one. Fix it, please.

If there's a site where Firefox warns about resubmission and IE does not, that's a surprise and we want to find out what's going on. We designed Firefox to cache-for-session-history in a superset of the cases where IE caches-for-session-history. Please file a separate bug for each site where Firefox warns about resubmission but another browser does not. Include a URL and detailed steps to reproduce. Out of 5 such bugs, I wouldn't be surprised if we found 5 completely different reasons: bug in Firefox, bug in another browser, bug in an extension, site doing improper browser-sniffing, intentional difference in behavior between browsers. We simply don't understand what's going on here enough to know which additional preferences would help, if any. Maybe a couple of non-controversial fixes will take care of most of the problems and no prefs are needed. Below, I've summarized the suggestions in this bug's 111 comments. Caching behavior: 1) Use the cache more for session restore (bug 493436). 2) Stop treating https specially (?). 3) Pref to ignore no-store header, per-site (but see bug 268037 comment 3). 4) Pref to ignore no-store header on all non-https sites. What to do when a POST page isn't cached and you hit Back: 1) Show an info page instead of a dialog (bug 451250). 2) Skip the page in session history (bug 493437). 3) Explain why each page isn't cached (bug 493438). 4) Load the URL as GET and hope it's useful (bug 322984). 5) Show the data that would be resubmitted (bug 295728). 6) Let sites tag POST forms as safe to resubmit or idempotent. 7) Pref to auto-resubmit, except on https sites, where POSTs can be financial. 8) Pref for what to do, per-site. Other suggestions: 1) Allow submitting forms in a new tab or window (bug 17754). 2) Don't warn when coming back from offline (bug 493435).

Maybe some of you have set the hidden pref browser.cache.memory.enable to false? Firefox is willing to cache SSL data in memory but not on disk, so this may explain the issues for some of you.

NO, i have true in browser.cache.memory.enable, but the useles POSTDATA STILL. I think are 2 problem differents. 1) pref per site with auto-resubmit. 2)Cache for the ACTUAL VIEWING PAGE. Is unnaceptable that firefox have no idea about the page is displaying right now. Maybe the cache can be stored encrypted. If i want see source code the data is required again to the webserver. This is unhappy for web developers work.

Comment 114 sounds like it's talking about "view source", which is not related to this bug as filed. Please file a separate bug on that issue, and make sure to point to an actual page that shows the problem.

I found this URL which tells you how to rebuild firefox, it also tells you where to edit the source code. https://www.travibar.com/forum/index.php?topic=3.0 Enjoy :)

How many years does it take to get this fixed? There needs to be an advanced option that just reloads the page and no 'resend POST' nagging window is shown. At least have an option to be able to turn it off(after the first warning) on all future reloads on the same site. Otherwise please provide me with info about what locations need to be edited with a hex editor to remove the window altogether. Or a patch would be fine also. I really don't want to compile the build myself. Thank You.

We all understand your frustration, but there are only two choices - reload the page without any form fields filled in, or reload the page and send the re-data that resulted in the form fields being filled in. I think. But even if I'm wrong about that, your complaint isn't with Mozilla. It's with whoever designed the webpage you're looking at.

??? The webpage doesn't nag me when I reload the page, FireFox does. I want to repeat the same action over and over every so often, and I do not want to click a nag window to do so. The odds that webpages that I want to reload will be updated to eliminate this, are almost nil. Come on now, a browser shouldn't be dependent upon a perfect world, especially a browser platform such as this. It should be what people want. And obviously developers think they know better, and are not willing to put out a better product.

obviously the result of this "closed mind" will be that the people go to another browser. And firefox will go to deprecated software. FIRST, the anyoning leter es USELESS (Read my arguments before expayed). SECOND, is firefox responsability keep the data that is displaying (cache). THIRD, is responsability of the user have the choice to resend data silently. I agree that need come disabled by default and only the users that know what does use it. FOUR, is responsability of mozilla developers/mintainers give a usable software listen the user ask. FIFHT Is NOT a atribution of mozilla, manage or tell us what the user can do, or wich site we must visit. (this respond to the comment #119) Last:i don know why was complexed a simple thing. If a software is not usable, the software need be discarded. And my post is EXACTLY to contribute to the project and avoid that firefox become only in a old memory

(In reply to comment #51) > > If a page that is the result of a POST request has been expired from the cache > (usually this only happens because the site requested that it be no-store for > security reasons) and the user navigates to it through session history, what > should happen? Current behavior is to ask the user whether to repeat the > request; this is suboptimal because most users have no clue what to do with > that question. So we need a better approach. > I would like to have two options - RESEND, repeating the request - DUMB SHOW the outlook of the previous page view, in a non-changeable and non-operable way, by using all possible cache means.This view can be special and can be "grayed" for example to show that you cannot really do anything with the expired view. Sometimes when browsing you just need to see information from the previous page just to look at it as it was exactly rendered.

Also, if there is any developers, and not whiners, could you please point to the pieces of code that make that "back" functionality? I would like to browse through code, and possibly make a patch.

(In reply to comment #123) > Also, if there is any developers, and not whiners, could you please point to > the pieces of code that make that "back" functionality? Toplevel "back" function as called from the UI: http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#3367 (nsDocShell::GoBack). This probably lands you in nsDocShell::LoadHistoryEntry, which calls nsDocShell::InternalLoad. That calls nsDocShell::DoURILoad. That has some code starting with this comment: 8233 /* If there is a valid postdata *and* it is a History Load, 8234 * set up the cache key on the channel, to retrieve the 8235 * data *only* from the cache. that's relevant here. Then there's some HTTP channel code that tries reading from the cache and so forth; I can point you to that if you like. When it discovers that the data is not in the cache anymore, it ends up in nsDocShell::EndPageLoad with aStatus == NS_ERROR_DOCUMENT_NOT_CACHED, which is where the dialog is posed (see the ConfirmRepost call). If you have any followup questions, feel free to mail me or ask in the mozilla.dev.platform newsgroup or catch me on irc.mozilla.org in the #developers channel. Thanks for looking at this!

Come on guys fix this please, its really annoying and I find myself painfully having to use IE because this infuriates me so much on some websites.

Here-here! Can't someone fix this? It can't be that hard! (In reply to comment #122) > I would like to have two options > - RESEND, repeating the request > - DUMB SHOW the outlook of the previous page view, in a non-changeable and > non-operable way, by using all possible cache means.This view can be special > and can be "grayed" for example to show that you cannot really do anything with > the expired view. Sometimes when browsing you just need to see information > from the previous page just to look at it as it was exactly rendered.

This comment is in reply to comment 112 which seems to be asking for end user input. I have used Ff since version 1.6, but have today uninstalled it simply because this bug is making me crazy. I hate that I had to do that, but it really makes the user experience a bad one. I am not a developer, coder or anything like that. I have been a computing end user since the mid 80s. (graphic design) I have seen A LOT of software in those years, some really, really bad, some really, really spectacular. Ff was really, really spectacular to me until this issue started consistently cropping up, and it seems to only be getting worse. I was stunned to see this was first reported in 2002! It hasn't really been an issue for me until the past 6-8 months. 90% of my web usage has been restricted to a dozen or so sites for the past 5-6 years. I won't say this issue NEVER appeared before 6-8 months ago, but it didn't degrade the user experience like it does now when you get 15-20 of these *^@!#*$ing dialog boxes in a day. Me = Windows XP, SP3 / IBM T42p Thinkpad. I am really crazy about updating, and usually got the Ff updates the day they were released. I also use only one AddOn, NoScript. Ff + NS, to me, equals the best, safest surfing experience anywhere. Period. (Actually, 2 other Java add-ons seem to appear out of nowhere, but Java cannot be defeated, so I leave them alone) eBay = The absolute worst place for these to appear. (at least for me) I have been using eBay daily since 2004. This was never an issue, as I said, before 6-8 months ago. I scroll through the category listings, select an auction page to view and then (without bidding, or clicking on anything on the auction page) hit the back button. BAM, the dialog appears. It has come to the point where 30% of the auction pages I view produce the dialog box after I hit the back button. The odd thing is it isn't always reproduceable. Sometimes it is, sometimes it isn't. Depends on the page. Yahoo = Rarely, I will be reading a yahoo email, and hit the back button to go back to my mail box, and the dialog appears. This has happened a couple of times in the past six months. Misc = I can be reading static text pages with no form boxes on them (Like ComputerWorld for instance) and I get the dialog box when I hit the back button. Situations like these are never reproducable. This makes no sense to me at all. The fact that I am not a programmer, able to understand the situation, makes it all that more frustrating because I can at least understand that it shouldn't be happening. Just reading the comments here, this seems to be a safeguard related to form data. (ie, the ordering of 10 computers.) The odd thing is that on pages where I hit the back button and would EXPECT to get the dialog box, I don't. Like making a payment, or signing up to a new site. I can hit the back button and the form on the previous page comes back without the dialog box. Sometimes the form data that I entered is still present, sometimes it is not. I get it that technophobes need to have their hands held during their "surfing experience" and that is probably the whole point of this dialog box. But those of us that have been using the web for a long time see this as just another M$-like clippy character. I don't need/want to have my hand held. PLEASE, just give me a global opt-out radio button in options. Bury it as deep as you like. Make it impossible for technophobes to find or understand. Please, I'm begging here, please just let me make the decision to get rid of the mozilla clippy once and for all. I hope this has been useful, on some level at least. I am willing to help as much as I can to the extent of my abilities. Please contact me if I can. I LOVE Ff, it is the brower of choice for me. But I've thrown the bitch out for continually dissing me, and MY surfing experience.

Please do something about this. I understand it is safer, but let me decide if I want to disable the warning. For peoples that are going insane over this like me; I found that using the extension "coral IE TAB" and swithing the rendering engine to IE within Ff for pages that pop ups with this warning solve the problem.

I am doing web test automation using Selenium and this message is one of the biggest showstoppers I have encountered. Unfortunately Selenium can not automate such browser popups and this means that there are some tests I can not automate with Firefox. Please, think of some way to disable this message, a hidden about:config option will be fine for me.

i agree, but sadly, seems to me that the real problem is the arrogance of "YOU MUST DO THE THINGS IN THE WAY AS I SAY AND SHUT UP". Thereis no one comment of a programmer saying "i will do, but wait me".

>I am doing web test automation using Selenium and this message is one of the >biggest showstoppers I have encountered. Unfortunately Selenium can not >automate such browser popups and this means that there are some tests I can not >automate with Firefox. >Please, think of some way to disable this message, a hidden about:config option >will be fine for me. What exact behavour do you want instead? Silently repost old data? Have means to disable cache misses (ignorance of no-cache?)

Ignorance of no-cache will be fine for most applications.

I believe most of the posters to this bug would like pages accessible via the back and forward buttons to be cached regardless of what the webserver requests, so that they can be redisplayed just as they were without having to revalidate them. I think this is what most users actually expect these buttons to do, which is why they find the popup warning so irritating. Think of it as keeping every old page open in a hidden tab and just using the back and forward buttons to select which tab is displayed. I would probably do this a lot manually if only it was possible to open POST requests in a new tab or window, but that's a regression for another bug (bug 17754).

I can't speak for most posters, but for myself, the problem with this bug is that it prevents viewing any page in the history. I don't mind not being able to see pages that are marked as no-store or which have expired, I do mind not being able to navigate past them in the history. Whatever comes up when I hit 'back' and get to a page that cannot be displayed should not prevent me from hitting 'back' again and getting to an older page.

Shad, you've nailed the discussion perfectly. However, comma, not letting you see a page in history is exactly the purpose of the "bug," which is not a bug - unless you want to re-send the page (along with whatever $$ you sent with the page the first time). The WEB PAGE CODER - your bank or whoever - has decided that they DON'T WANT you to make this mistake. Yes it is irritating. Yes a better UI would be nice. But it ISN'T Firefox's doing. It's the bank, or the "pron" site, or whoever, that is preventing backpaging. For the Firefox crew - perhaps the page could be redisplayed without any actions or resubmits being sent?

I don't mind that I can't see a particular page marked that way, the problem is that navigating away from a page marked that way effectively disables the history mechanism entirely (unless I'm willing to place my order again). Just fixing that and nothing wouldn't be enough to make the UI not suck, but, for me, it would make a suck a whole lot less.

If you want to skip over a page marked "no-history", you could theoretically use the small down array next to the forward button, which lets you chose among several pages visited recently.

That's true, but for that to be an effective solution I would have to know the previous page was marked no-store prior to hitting the back button. So, here's a new suggestion: have the back button look different when that is the case, and similarly mark no-store pages in the back menu. I don't think that would resolve this bug (and I'm not sure it would stop me from getting trapped by going back to a no-store page), but it would be a help. (something similar might help with the problem of hitting back and getting immediately redirected to the page you hit back from)

(In reply to comment #132) > >I am doing web test automation using Selenium and this message is one of the > >biggest showstoppers I have encountered. Unfortunately Selenium can not > >automate such browser popups and this means that there are some tests I can not > >automate with Firefox. > >Please, think of some way to disable this message, a hidden about:config option > >will be fine for me. > What exact behavour do you want instead? Silently repost old data? Have means > to disable cache misses (ignorance of no-cache?) In my case (test automation) I would like to just silently repost the old data. I realize that this is not what most people want though, so maybe this should be configurable behavior.

In bug 565793 (duplicate of this one), it is pointed out that apparently web servers may request that a page should not be remembered in history, for purpose of privacy (so that the next user on a shared computer can't get to the previous one's bank statements by keeping clicking back...). If so, could anybody post a pointer to the RFC where such standard is defined? After a cursory search, I couldn't find anything in the RFCs about disabling history. To me, the use case seems to me too farfetched to warrant crippling a browser in such a way. Indeed: 1. Browsing your bank statements from a cybercafé is dangerous (keyloggers, etc.) no matter whether history allows the next guy to go back to them or not. 2. If you are only concerned about leaks due to history, why not close the window or Tab when done? That way, the history is gone as well. For situations where the window cannot be closed (kiosk mode), the "feature" could still be kept, but only when in kiosk mode.

Mozilla browsers would appear to not be compliant with the HTTP/1.1 specification. RFC 2616 section states: "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." Section "14.9.2 What May be Stored by Caches" says about the "no-store" directive: "Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system (e.g., with a "Save As" dialog). History buffers MAY store such responses as part of their normal operation." Comments here suggest that IE and Opera do comply with this by simply redisplaying the old page without attempting to revalidate it, thus avoiding confusing questions and any risk of paying for things twice. Note, the first quote above explicitly allows an optional setting to refresh expired pages, as some people would like. It also recommends against warning or error messages of the type being complained about in this bug, which ordinary users have no idea how to answer. Odd that it's Mozilla browsers apparently not complying with the specs and confusing users.

Very interesting, Roger, thanks. I think this makes it pretty clear that this is indeed a bug, and not a privacy feature.

Yahoooo !!!!!! Steve VanSlyck please read the comment #143. YES IS A BUG. And i ADD the USER must be assume the responsability of choose store private data in the disk or not. Is not programmer/developer attribute. As was mentioned before OPERA AND IE WORKS FINE !!!. Other aspect when i open FF i get 7 or 8 asking for postdata, BUT NO ONE is bank page. Including one aspect NOT COVERED is that FF asume no-cache directive EVEN WAS NOT SPECIFIED. I do web aplications in 3 languajes. Example in perl, I write: print "Content-type: text/html\n\n"; print "<html>"; ...... print "</html>"; The page receive a web form,BUT THERE IS EXIXT NO NO-CACHE TAG. BUT EQUALLY i get the mentioned "postdata warning". So IS ANOTHER BUG this.

Here's more, from the same RFC: 14.9.2 What May be Stored by Caches no-store ... "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, ... ^^^^^^^^^^^^ So, all this is only about on-disk storage, not about in memory storage. The "attack scenario" that this is concerned about is somebody going over the disk or backup tapes after the session, not somebody using the back button because the user forgot to close a window. In order to prevent inadvertent non-volatile storage due to swap, couldn't firefox just use the mlock() system call (... which it would have to do anyways, because the page data will always be in memory, even if only for a few split seconds between arrival and display) Using 2 small CGI scripts, I confirmed that we get the troublesome behaviour only with no-store, not with the more common no-cache, which seems to prove to me that firefox (3.5.9) already has most logic in place to support different retention policies for its cache and for its history. Fixing this should thus not be extra-ordinarily difficult, as most parts of the fix are probably already in place. So when can we finally get a fix for this 8 years old bug? On the other hand, most "normal" (i.e. not particularly privacy-sensitive) web sites would not have a need to use no-store rather than no-cache. So if you see the troublesome behaviour elsewhere than at your bank's site (or similar), complaining to the website operator is definitely in order too.

Further tests showed that if the URL is https rather than http, even "no-cache" produces the bug, not just no-store. IMHO, this is much more serious, as this is a situation which is much more frequent than no-store. Could it be that somebody assumed here that https means "privacy must be important" which means "so we better make sure that even no-cache pages don't end up in the history"... ... causing a usability nightmare, and actually lowering either reliability (if app developer chooses to drop the no-cache header in order no to bother his users) or lowering security (if app developer or webmaster drops https instead) While https does indeed mean that the user cares about privacy, it's meant to protect against eavesdropping on the wire (a plausible scenario) rather than against untrusted people using his computer afterwards who might be able go back through history (an unlikely scenario). Please don't mix the threat models here. Moreover, with many https pages, the only thing actually being private is the login password and/or the session cookies, which aren't available in the history anyways. With a properly logged-out session, it's not as if the user could actually follow any links or click any buttons from the pages in history, so the potential of mischief there is low. So why the fuss? If no-cache+https could behave the same way as no-cache+http, this would already be a big improvement over the current situation, and should be trivial to fix for somebody who knows the code (unfortunately, not me).

I've put a couple of test cases online: http://www.lll.lu/~aknaff/bug-reports/mozillaNoStore and https://www.lll.lu/~aknaff/bug-reports/mozillaNoStore This is both times the same directory, with the same pages returned, but one is http, and the other is https, and it is interesting to see the change of behaviour of Cache-Control: no-cache between the http and the https case. There are two links (GET) on the start page, and 2 buttons (POST). They lead to one CGI script which returns a no-cache header, and to another one returning a no-store header. Both these scripts include a date in their output, to make it easier to detect reloads. Each has a link leading to a "landing" page, from which you can go back. The following can be observed (tested with 3.6.3, and with a couple of older versions) http + no-cache : no reload on back http + no-store : reload on back https + no-cache : reload on back (IMHO, the worst case of this bug, as this is the most frequent situation) https + no-store : reload on back As witnessed by the changing (or not changing) date, the Reload happens independently of whether the page was fetched by GET (clicking on the link) or POST (clicking on the button). Only difference is that with POST, you get the noisy warning, but the actual reload also happens with GET. Nowadays AFAIK, sites with Cache-Control: no-store are reasonably rare (and for those who have it, it is in most cases justified). However, pages with Cache-Control: no-cache are incredibly common, and many of those use https. So that particular case really needs fixing. Thanks.

Why does firefox ever automatically reload a page when going back? Isn't that history mechanism "meant to show exactly what the user saw at the time when the resource was retrieved"? Reloading a page violates that (and IME it does occasionally show something different that loses the thing I went back to see). Even if what I saw the first time can't be displayed (for whatever reason), automatically reloading the page doesn't seem like the right thing to do. Is this postdata dialog a symptom of that problem? It might be appropriate for that (or a similar but better worded) dialog to appear when I hit reload on the result of a POST request, maybe the root problem here is that the history mechanism isn't acting like a history mechanism.

(In reply to comment #149) > Why does firefox ever automatically reload a page when going back? [...] Actually, in most cases it doesn't. Here's an experiment to prove it: Click the login/logout link near top right of this page, and, after toggling your logged-in/out status (by logging in if you were previously viewing this page while logged-out) use the "Back" button or dropdown to come back here: the link still reflects your "old" logged-in/logged-out status. Now refresh the page by clicking the reload button: the page refreshes, and the link shows your "new" status.

(In reply to comment #150) > Actually, in most cases it doesn't. Unfortunately, in many cases it does. ... and it appears that the most frequent of these is not no-store, but rather no-cache combined with https. This can however be worked around on the web server by using different Cache-Control settings: Header always edit Cache-control no-cache "private, max-age=0, must-revalidate" For the cache, this is (mostly) equivalent, but for the history, it makes all the difference.

no-store & no-chache are ASSUMED by default by firefox. My web server ( apache ) has no one configuration with these directives ( i checked it RIGHT NOW ) My web application has no header with these content but the result is thas webpages ARE NOT cached or stored. This is a posiblity that we found ONE of the start point to solve a 8 years problem....... 8 years without solution???

Schmitz, please ask for help on support.mozilla.com if comment 113 doesn't help. What you are seeing is not normal.

Jesse: Comment 113 talks about separate caching defaults for ssl, so I tested whether maybe it is related to the issue of not keeping history of SSL pages if no-cache. Here's what I observed: 1. browser.cache.memory.enable was _already_ on for me. 2. Even switching browser.disk_cache_ssl on didn't make the bug go away for https://www.lll.lu/~aknaff/bug-reports/mozillaNoStore/no-cache.cgi Christian: for me, normal caching works (if no particular headers Cache-Control are sent), as shown by https://www.lll.lu/~aknaff/bug-reports/mozillaNoStore/none.cgi Maybe, if you observe lack of caching on CGI scripts, you are missing a Last-Modified header? At least that was the case that I had initially, when I set up those example scripts. I presume that without a Last-Modified header, firefox has no way of judging the "freshness" of a page, and thus prefers not to cache it? However, even if a page is not cached due to absence of Last-Modified, the history still works (unless additional headers are present). Btw, I've now added a page for this to my test-case: https://www.lll.lu/~aknaff/bug-reports/mozillaNoStore/missingLastModified.cgi All: comment 112 suggests filing different bugs for the different cases where history doesn't work. Is this suggestion still valid? If so, how to prevent that these additional reports are flagged as duplicate to this one here?

Alain, thanks for creating those testcases. That's the kind of thing that will make it easier to find out if different users are experiencing different behavior. It would be great if you added pages that post to each of those URLs, so we can see the POSTDATA dialog in addition to seeing the timestamp change. Oddly enough, Firefox does cache https://www.lll.lu/~aknaff/bug-reports/mozillaNoStore/no-cache.cgi for session history for me. I'm not sure why.

I stand by my suggestion in comment 112 to file separate bugs on all the things that can cause history to not work when it should. Bug reports with clear, complete steps to reproduce are usually not indiscriminately marked as dups :) But to minimize the chance of triagers marking your bug as a dup of this bug, you can mention this bug report, so they know you considered this bug. For example, after your steps to reproduce, you could write something like: Result: A POSTDATA warning. (UI might change in bug 160144.) Expected: Show the cached version of the page. (Firefox should have cached the page for session history because X. Browser Y does cache it.)

If you click one of the buttons at the bottom on https://www.lll.lu/~aknaff/bug-reports/mozillaNoStore, the do use POST (and they do trigger the POSTDATA dialog). For simplicity, the form submitted is empty, apart from each button itself. The links at the top use GET, but the bug can still be observed by noticing that on some of the pages the date changes when going back in history. Thanks for the hint about how to minimize probability of bugs being marked as dups.

I've now posted the no-store+https case as bug 567365

Re comment 150, yes, Firefox does pass that test (3.6.3 on OS X 10.5.8), but it also does automatically reload in some other cases, including those specified in comment 148. My question in comment 149 was not answered: why does Firefox ever automatically reload on back? Doing so violates my expectations, and violates RFC 2616 section 13.13: 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. Apparently Firefox behavior is inconsistent; sometimes it shows a past state and sometimes it tries to reload the current state. Why does it ever reload any page when the user asks to view the past state?

Out of curiosity, I just checked other browsers: Google Chrome: same behavior as Firefox (page evicted from history for no-store and for no-cache+ssl). However, in case the page has been evicted, and is the result of a POST, the UI is much better: it displays an entire page (rather than a modal popup) explaining what happened. You can then either explicitly click reload to refetch the page again, or click back once again in order to go further back (so access to pages before the evicted one is not blocked), but not forward. However, page is kept when just tabbing away from it and then back. Internet Explorer: no eviction from history for no-store. However, on an SSL connection, no-cache, no-store, must-revalidate+max-age all cause eviction from history. The UI is the same kind as in google Chrome (full page which can easily be skipped over). You can even go forward again. Page is kept when just tabbing away from it and then back. Konqueror: history is always kept. The argument "the page must be removed from history, because the web site asked for this" is weak in the case of invalidations which only happen on SSL. Indeed, in that case nobody decided to make the page no-cache+SSL. Indeed, the application programmer may have added no-cache due to other considerations (such as frequently changing contents). The guy who installed it on a web site may have installed it on an SSL site for other consideration (protection against eavesdroppers on the wire) without knowing that the app itself also sends no-cache. None of the two parties conciously decided to put no-cache and SSL together. So, arguing that firefox's behaviour is just following somebody's wishes not to have the page in history is ingenuous. No-store would be a stronger case (decision by a single party, and an equally simple "no-cache" readily available to just take care of changing content), but interestingly enough, Internet Explorer doesn't invalidate history on no-store.

I think there are three distinct problems here: 1: Firefox sometimes doesn't store pages in the session history when it should. 2: When going back to a page that is not stored in the session history, Firefox sometimes (always?) automatically reloads. 3: When firefox reloads a POST request, the warning about resubmission has a lousy UI. This bug is named for #3, and there are separate bugs for at least a few cases of #1; is there a separate bug for #2? Are there different cases for which there should be separate bugs?

> 1: Firefox sometimes doesn't store pages in the session history when it should. See comment 1 of bug 567365, where Boris Zbarsky even posted the guilty code fragment from nsHttpChannel: 2105 if (mCachedResponseHead->NoStore() || 2106 (mCachedResponseHead->NoCache() && mConnectionInfo->UsingSSL())) { Firefox doesn't store objects in history if one of the two following conditions are met: a. Cache-Control: no-store is set, or b. Cache-Control: no-cache is set, and page has been fetched over https So actually this should be _very_ easy to fix (just rip out the above conditional and its contents). Apparently, all that is stopping us is some irrational fear of banks blacklisting firefox over it. Do such banks still exist? Or did most fix their code and/or attitude? (this argument has been bandied about mostly when this bug was still new, i.e. 8 years ago). If they still exist, can anybody "in the know" please post a list, preferably with recent quotes of spokespeople from these institutions? Indeed, I'd hate it to be stuck with a poor browsing experience just because of the irrational fear of a bogeyman who has long left the scene... > 2: When going back to a page that is not stored in the session history, Firefox sometimes (always?) automatically reloads. If the page that is no longer in history has been fetched via GET, then it is transparently reloaded. If it has been fetched by POST, then the POSTDATE dialog pops up. In some way this makes sense, as the RFCs specify that a GET request should never have a side-effect on the server (such as placing an order, creating a forum post, ...) and thus can "safely" be repeated, whereas the same is not the case for POST. Well, that's the theory. In reality there are plenty of webapps which trigger side-effects by simple hyperlinks (GET), and others which use POST for actions without side-effects (in order not to clutter the URL displayed on top of the page). IMHO, this part of the behaviour is not the bug. The real problem is why pages are missing from the session history in the first place (#1), and not how the browser deals with their absence. > 3: When firefox reloads a POST request, the warning about resubmission has a lousy UI. Google Chrome and Internet Exploder 7 have similar issues of history non-retention (although the exact cases where it strikes (#1) are slightly different), but a better UI to handle them. Rather than popping up a dialog, they show a replacement page explaining what happens, and instructing the user to click reload when he wants to see a new version of his cached version. If the user is not really interested in the non-retained page, but in a page preceding it, he may just continue clicking back (which is not possible with Firefox' popup) > This bug is named for #3, and there are separate bugs for at least a few cases of #1; is there a separate bug for #2? Are there different cases for which there should be separate bugs? The issue is that if two bugs look vaguely similar, they are declared to be "duplicates" by the triagers, even if really they are about something else. However, what helps is including a small note about why you think these should be different from this bug, and they will be left up as an independent bug. That's what I did for bug 567365.

Everyone please keep in mind, IT ISN'T THE BANKS. It's EVERY coder out there who doesn't know what he (or she) is doing. If it was just the banks and the shopping carts I bet it wouldn't be an issue.

Exactly what coder error is this supposed to protect against? And how widespread is it still, in order to warrant annoying every single Firefox user out there?

Arggggh! Read Comment 51! https://bugzilla.mozilla.org/show_bug.cgi?id=160144#c51

And what exactly does that comment have to do with my question? What coding error does it underline that makes this "workaround" necessary?

The point is that you don't understand the bug - and I've got enough of my own homework to do. Read the comments.

Esou, hunn elo grad all 166 Kommentaren duerchgelies, an ech hunn eng gudd Nouvell: ech hunn alles verstan! Kënne mer elo eng Versioun vu Firefox kréien wou d'Browsing History anstänneg fonktionnéiert?

The problem that bothers me the most is problem 2 (automatic reload), so I've filed bug 569142 specifically about that.

(In reply to comment #168) > Esou, hunn elo grad all 166 Kommentaren duerchgelies, an ech hunn eng gudd > Nouvell: ech hunn alles verstan! Kënne mer elo eng Versioun vu Firefox kréien > wou d'Browsing History anstänneg fonktionnéiert? english please??? Or spanish for me... jejje The problem is simple the programmers have the right to decide what you can do and you cant.Dont letting to the user decide what is possible RELOADED careless and WHAT dont be reloaded. But the problem is NOT only into the anyoning POSTDATA window. If you try "view the source code" the data must be reloaded again. This indicate that the cache is very lacky.

All this patch does is replace the warning you get when attempting history navigation with a semi-bogus error page (actually the "Page not available offline" page) but at least you can click the "Try Again" button (which results in the form repost warning). I'm not sure how best to distinguish between this case and the genuine offline case; I would have expected the latter to return NS_ERROR_OFFLINE instead. Maybe it should?

How about preventing the problem in the first place, by not discarding the data from history?

We'll do some of that too if possible, e.g. in bug 567365.

> How about preventing the problem in the first place, by not discarding the data > from history? That's not possible in all cases, for user privacy reasons (aka "don't let the next person who walks up to the library computer after you hit "back" to see your bank account info).

> I would have expected the latter to return NS_ERROR_OFFLINE instead. Might be a good idea for a followup, yes, if you don't want to do it here. But you'd need to audit the callers. Why does the "Try Again" button end up prompting for repost, exactly? Because that performs a reload? One other note: you can tell apart the "genuine offline case" by checking NS_IsOffline, no?

> aka "don't let the > next person who walks up to the library computer after you hit "back" to see > your bank account info How exactly would the next person hit "back" when the previous user has closed the window? And who in his right mind would browse his online banking from a library computer?

(In reply to comment #175) > > I would have expected the latter to return NS_ERROR_OFFLINE instead. > Might be a good idea for a followup, yes, if you don't want to do it here. But > you'd need to audit the callers. Why does the "Try Again" button end up > prompting for repost, exactly? Because that performs a reload? Yes, LoadHistoryEntry checks for a reload with post data. > One other note: you can tell apart the "genuine offline case" by checking > NS_IsOffline, no? Ideally NS_ERROR_OFFLINE would never apply to a history navigation; you would always get NS_ERROR_DOCUMENT_NOT_CACHED in that case.

Ironically the NS_ERROR_DOCUMENT_NOT_CACHED mixup means that you don't get offline error pages for other protocols, such as FTP...

> How exactly would the next person hit "back" when the previous user has closed > the window? People commonly don't close the window. > And who in his right mind would browse his online banking from a library > computer? Someone who has no computer at home but is forced to use the bank's online features for various reasons (commonly needed nowadays for all sorts of stuff). Or were you thinking everyone is rich like you and has internet + a computer at home? > Ideally NS_ERROR_OFFLINE would never apply to a history navigation; you would > always get NS_ERROR_DOCUMENT_NOT_CACHED in that case. That should be fine; you know what sort of navigation you're performing (unlike the http layer!). That is, you could try to hack http to give the results you want, but it might be easier on the docshell end where you have more information.

> People commonly don't close the window. People commonly (nowadays) also open several tabs. And forget to close these. So shouldn't Firefox also invalidate the contents of non-active tabs, just in case it is bank data? And what if the user has more than one firefox window open, and has a window with bank statements hidden behind the maximized window that he currently works on? You know, some people really like maximized windows. He could the inadvertently leave his seat in that state, and somebody else could see his bank statements by just closing the maximized window that covers all the others. And some people may just get easily distracted, get involved in a conversation, and completely forget about their bank statement sitting out in the open on the screen. Maybe Firefox should also toss away the contents of such pages if it detects UI inactivity of more than a couple of seconds? And then, this hooks into heuristics which are satisfied by many non-bank sites (which is why people complain), not satisfied by some bank sites (who might use unique per-session URLs to control caching, rather than Cache-Control headers), and explicitly discouraged by the relevant RFCs. And if the next person knows about the small black "down" button near the forward arrow, he can skip right over the invalidated pages, and visit the form where the user entered his password... which sits there undisturbed, because this bug protects only data sent by the server, and not form data filled-in by the user. How about you fixed the actual privacy issues such as bug 482950 which flashes your private mails (and also bank statements, if the circumstances are just right) to coworkers to which you give a demo? And for that bug, you're mostly a sitting duck, unless you tell your window manager to ignore those obnoxious focus and desktop change requests by Thunderbird and Firefox?

(In reply to comment #180) > And if the next person knows about the small black "down" button near the > forward arrow, he can skip right over the invalidated pages, and visit the form > where the user entered his password... which sits there undisturbed, because > this bug protects only data sent by the server, and not form data filled-in by > the user. Which doesn't get saved, since it's in a password field, and it has autocomplete=off, so it's not stored in password manager either.

autocomplete=off is not standards compliant, unfortunately (does not validate).

Yes it is, at least if you use a modern HTML5 validator. It's obviously not HTML4 because it was invented after HTML4, but that only matters if you're a pedant.

What is the real reason why this 8-year old bug doesn't get fixed? It's obvious that the real reason is not technical. 1. As has been shown, it's easy to fix. 2. Popular demand is in favor of a fix. 90% of the comments call for a fix, and the 10% percent remaining feel that they need to resort to name-calling to "bolster" their position. So, when will this get fixed?

> So shouldn't Firefox also invalidate the contents of non-active tabs, just in > case it is bank data? 1) People don't use tabs as much as you think. 2) People _do_ click the bank's "log out" link. > What is the real reason why this 8-year old bug doesn't get fixed? No one has written a patch. In particular you (who can do it as well as anyone; the source is open) haven't. Of course now that Neil has people are adding noise instead of just letting things be, making it harder to fix the bug. So how about we all pipe down and wait for the technical issues to be sorted out?

> No one has written a patch. In particular you (who can do it as well as > anyone; the source is open) haven't. Here is a patch.

That's not a patch for _this_ bug (which can still happen if something as simple as cache eviction happens). If you want to change the no-cache SSL behavior, you want bug 567365 (as you well know!). Now can you stop adding irrelevant noise to this bug, please?

Comment on attachment 450184 [details] [diff] [review] FIx for this issue On a technical level, this patch is wrong even for bug 567365; it doesn't change the history heuristics in nsDocShell.cpp.

Why are you asking for a patch if you don't want one. Or did you think I was unable to make one? Now please shut up.

Alain, you asked why THIS BUG is not fixed. Then you posted a patch for a totally different bug. That doesn't get _this_ bug fixed.

Weird... with my patch applied, the POSTDATA dialog no longer appears.

No longer appears with one particular set of steps to reproduce that can trigger it. Try taking a build with your patch, doing a POST, clearing the cache, then hitting reload and watch the dialog appear.

I tried this... but in that case, the history buttons (back and forward) are greyed out, so the case is moot...

Comment on attachment 450192 [details] [diff] [review] Possible patch This looks good. I love all that code going away!

> The requested document is not available in Firefox's cache. > As a security precuation, Firefox does not automatically rerequest sensitive documents. > Click Try Again to rerequest the document from the website. I think this is misleading. The *security* precaution is not caching it. Not rerequesting is an *integrity* precaution and only applies to POSTs. I'm worried that using the phrases "security precaution" and "Try Again" could lead users to repost without understanding the consequences, or not repost due to misunderstanding the consequences.

> but in that case, the history buttons (back and forward) are greyed out What does history have to do with it? See "reload" in comment 193. Jesse, good point. I'd like to get some UI love for those strings; I'll admit to not reading them that carefully. The error page is definitely NOT a security measure; it's a measure to avoid double-POSTs in situations when the document is not cached, for whatever reason. That's what the text should talk about.

> The *security* precaution is not caching it. No, that's not a security precaution, but just an ego precaution for those developers that wrote that code in the first place. It's not a security precaution, because in the hypothetical "viewing bank statements on a library computer case", the next person could check "Work offline" just as well as the original person could, and get back to his bank statements... FAIL. Moreover, as the page was actually cached, I guess it could even wind up in the on-disk cache, even defeating the RFC's original intent for no-store. DOUBLE FAIL.

> the next person could check "Work offline" just as well as the original person > could, The fact that this works is a bug that just needs fixing. > I guess it could even wind up in the on-disk cache no-store doesn't end up in disk cache. See the check for no-store in nsHttpChannel::InitCacheEntry.

To comment #185 >> So shouldn't Firefox also invalidate the contents of non-active tabs, just in >> case it is bank data? >1) People don't use tabs as much as you think. >2) People _do_ click the bank's "log out" link. I have 20 tabs simultaneous, and i know people that keep the bank open. And YOU cant say what people must do. To comment #186 > If you want to change the no-cache SSL behavior, THIS BUG is not ssl dependant. Finnaly seems that working in a solution

Comment on attachment 450192 [details] [diff] [review] Possible patch Sorry for the delay with the UI-review, here's my feedback: We need to be sure to avoid explaining how the Web works in our messages to the user, and focus specifically on the user's potential actions and consequences. This patch proposes a two steps, a content area message explaining that the page is expired, and the current POSTDATA dialog box that explains to the user that they need to resend information. Chrome gets around the issue of what to show in the content area by making the content area the POSTDATA message itself, and asking the user to hit the reload button. There are two things that are nice about this approach, it focuses on a single topic (while we focus on two different topics), and the user has to read and understand the text before they can take action, there is no whatever button (we provide two whatever buttons for the non-reading rabidly clicking frustrated user). Ideal solution (follow up bug): We transition the postdata dialog box to a tab modal message using our new panel based notification UI (we are also using these tab modal panels for javascript alerts in bug 562258, slow script, etc.) In the normal case this message will overlay the content area, with the background slightly whited out to indicate that the user needs to take action. In the event that Firefox has decided not to cache the page, we simply place the panel over a blank page. The messages focuses solely on the user's choice of resending information (the fact that the page is blank is ignored). Also I think we should instruct the user to hit reload to remove the whatever button and force comprehension, Chrome's approach should reduce unintentional errors. Immediate solution (to resolve the issues with no-cache and no-store): Show blank pages if we don't cache anything, and immediately trigger the current POSTDATA dialog. It will be window modal for now, which isn't great (and doesn't resolve the frustrations noted in the first comment). However, introducing a second step that focuses on implementation level details isn't the right way to address the modality problem.

Wild idea: why don't we always go two steps back in history instead of the one that relies on the POSTDATA? We should be caching the content of the page before, and that would make it much more clear that the action would be replayed.

Had a quick discussion with jesse, I was slightly confused on some of the details of this bug. new proposal: Ideal solution for the case of no-cache or no-store: When the user hits back we just take them back to the page in which they started submitting data, and fill out the form for them again. This provides way more context about their actions (moving money between accounts, buying a car, etc.) than a series of messages. Immediate solution if we want to check this in: Keep the in content message approach from this patch, but include the post data dialog text, and make the action button resend (no subsequent dialog) instead of try again. Unrelated case of normal postdata dialog: we still need to switch to a tab modal panel when the user hits reload after going back on a page that we are pulling out of cache.

yep same thing beltzner said (might be more than two steps hypothetically, but either way just resending the final step in a complex process will probably break the site either way)

Skipping pages when hitting back will confuse people who don't understand why a page was skipped. Especially on broken sites which POST when they don't need to and/or defeat the cache when they don't need to. (And it would **** me off whenever it did it to me - my tools should do what I tell them, not what their author thought I would prefer!) I don't see a coherent way to tell the user what's going on when it happens. I think it would be way better to have the info page and confirmation panel recommend going back to the form.

I think we should turn this into a meta bug, depending on bugs which effectively describe what "better UI" actually means. It should depend on (at least) the following bugs: bug 361014: grammar changes to POSTDATA dialog bug 324157: make POSTDATA dialog nonmodal bug 322984: include option to GET rather than re-POST bug 569142: don't reload POST results when navigating session history bug 493435: when POST failed because browser is offline, don't treat the retry (after going online) as a reload bug 493437: [option to] skip non-cached POST responses when navigating session history bug 515223: create a whitelist for pages which will automatically re-POST without invoking the confirmation UI. (maybe) bug 295728: allow view/edit POST data before resubmission

Add to this list: bug 567365: don't exclude anything from session history in the first place

...and for heaven's sake don't offer buts with labels of "OK" and "Cancel" to questions which take YES/NO answers.

arghh! i can't believe i first posted to this irritating bug in 2006 and it is STILL not fixed! everything from paternalistic and patronizing programmers saying "won't fix" to ensure that the 'people' are always protected, as if they are all too stupid to make their own decisions and must be tied up in bubble wrap, to the rugged individualists who shout 'darn the torpedoes, full speed astern'. there are other browsers out there that do not have this idiotic message, but handle the situation somehow. intenet explorer in all it's incarnations,chrome, and i'd guess opera for three examples (i hate opera so have not tried it). how come they work unobtrusively when you press the back button? i'm sure one of you smart programmers can reverse engineer what they do. pick one of their methods, pick a new method, add an opt-out in the config, compromise between the two camps, but DO SOMETHING. i'd hate to wait another 4 years. 'and "won't fix" is NOT an option. and please add 'yes' and 'no' to your button vocabulary.

Depends on bug 200208: Clearly distinguish between history & cache

jejejej, i hate the postdata dialog, and fight agains pedantic programmer that say how i can use the web, the literal expresion was "dont open multi tab". but in the middle new dialogs popups "document.location = null" and another items. Really to growup a project the first point is LISTEN to the users. In every item of the life 100 people say "this is ****" and go to other product. But ONE, yes only ONE post "Hi guys there is a problem some dont like". This happen with a Restorant, Hardware, Software, Car etc etc etc. A smart manager know this ( 100:1) relation and take note of the customer report. Is true is impossible that some like to all, but is in the skill of manager the progress. Take a look 200 people of around of the world speaking in non matern language..... this change the report relation to 1:1000 or 1:2000. I already was demostrate the useless of the dialog, but i will repeat. when you open the browser ( with 20 to 25 tabs) the dialog appears with blank background, and blank URL bar and the postdata dialog asking 10 to 15 times about blank pages. The only way to finish opening the browser is say YES TO ALL. So all pedantic discussion proteccion abbout bank data was useless anyway. I like the working idea about a blank page asking "are you sure" IF ONLY IF, is possible know some aditional data of the page to reload. For example: 1) the tittle of the page is displayed 2) the URL of the page is displayed 3) optional ( a photo capture of the page). I know this is a GNU project, every is do by love to the project and maybe we request one response like a propietary soft. But, the fact is that the post of the programmers only say "we dont want change, with excuses proved as falses". If a programmer was writed "letme a couple of months that i am with personal problems", the character of discussion will be different. no-cache no-store is not mandatory. in a page without these sentences, and in a server that dont have this, equally appear the postdata dialog when reopen the FF o when press F5 to reload. That strange if i press F5 is for reload, so i am concient that i request reload..... but the dialos equally appears????

(In reply to comment #212) > *** Bug 619678 has been marked as a duplicate of this bug. *** Great to see that this topic is discussed already. I just want to make shure my ideas can be found in this thread as well – Since I hadn't time to go through this long thread I hope there may be a new point of view in my initial report: <blockquote> The Problem: Every time I click the back-button to get back to a search result that has been send by POST I get this annoying modular dialogue asking me, if I want to send my data again. This is wrong for a number of reasons: - the user cannot understand what the problem is and consequences are but has to make a decision - the modular dialogue is anoying - it breaks my usage-flow - it unnecessary in most of the cases The Solution: It would be best for the user's UX not to have such a dialogue at all. Solution 1: POST without asking. Unfortunatelly we cannot do this (I suppose), because we cannot trust website owners to build their sites in a way that dont break by multible posts (like comments that are published twice…). But Firefox can be much more intelligent in deciding, what to do in special situations. For example: There is no harm in sending a search-form again and again. So why ask the user? Solution 2: Have a Checkbox "remeber for this website www.domain.de/search.html – So I as a pro user can check this box and be not to be bothered again about this on this specific page. Solution 3: Check for page-names and post-variables. If they contain "search" or "q" (query) just send the POST again. Solution 4: Like 3 but just show the page from the cache and dont ask. The search result is stil up to date in most cases. Solution 5: Define some kind of meta-tag that allows site-owners to tell Firefox what to do (like "dont ask, just use cache" or "post each time the page is loaded" or…). Solution 6: /There are probably more and better solutions, so please add them./ Reproducible: Always Steps to Reproduce: 1. go to some site that uses this kind of request – like http://eztv.it/search/ or something 2. search 3. go to a detail-page 4. use the back-button 5. there is the dialogue… "To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier" (or similar, according to http://stackoverflow.com/questions/2505289/ctrlr-in-firefox-for-refreshing-page-and-its-problem-to-my-php-code) </blockquote>

(In reply to comment #213) > Solution 4: Like 3 but just show the page from the cache and dont ask. The > search result is stil up to date in most cases. > > Solution 5: Define some kind of meta-tag that allows site-owners to tell > Firefox what to do (like "dont ask, just use cache" or "post each time the page > is loaded" or…). This exists but the site has to use the right tags for the page to be in the cache at which point we will just show the page from the cache.

The back button should be using the history, not the cache. See bug 200208. Tobias, it's less helpful to repeat suggestions as your own and more helpful vote for bugs that represent the solution you prefer. I mentioned several related bugs in comment 206, and more are mentioned in many other comments. I think your comment 213 is the first time I've seen the suggestion of skipping confirmation based on a heuristic analysis of the postdata; I suggest filing a bug for that, marking it as blocking this bug, and briefly saying so in a comment here (as I did with comment 169).

For that specific use case it'd be easier/less risky than heuristic analysis to detect HTML5 types like input type="search" http://www.w3.org/TR/html-markup/input.search.html but whether that'd be filed as an option of that new bug or as a competing bug is not clear.

(In reply to comment #215) > Tobias, it's less helpful to repeat suggestions as your own and more helpful > vote for bugs that represent the solution you prefer. (...) > think your comment 213 is the first time I've seen the suggestion of skipping > confirmation based on a heuristic analysis of the postdata; I suggest filing a > bug for that, marking it as blocking this bug, and briefly saying so in a > comment here (as I did with comment 169). Hi Shad, thanks for the help – I am still figuring out how the bugzilla-community/-system works :). I will do as you suggest (and reference Mardeq's idea).

Still broken in 4.0.1

(In reply to comment #203) > Immediate solution if we want to check this in: > Keep the in content message approach from this patch, but include the post > data dialog text, and make the action button resend (no subsequent dialog) > instead of try again. This does not appear to be a trivial change. (In particular there appear to be a number of edge cases to take care of.) Would you mind if it was split off to a separate bug?

In the Reload case, we don't want to remove the ability to cancel. Should we replace the dialog with an infobar or doorhanger when reloading? (It looks like the patch doesn't touch the Reload case -- it doesn't remove the other ConfirmRepost call or the confirmRepostPrompt strings.)

In the back-button case, we should reuse the text from the dialog, which focuses on the choice of repeating what might be a transaction: "To display this page, %S must send information that will repeat any action (such as a search or order confirmation) that was performed earlier." But instead of a [Cancel] button I'd show a [Go back] button or link. Maybe "_Go back_ to see what would be resent." We could also have an expandable "Technical details" section that explains the three factors that led to the page not being shown. It would explain which parts are Firefox's fault and which parts are the web site's fault. More importantly, it would suggest fixes if any are available, and allow users to file better bug reports. * www.bankofamerica.com caused the page to self-destruct after being viewed. - or - * Firefox's network cache is disabled. [Options…] - or - * Firefox's network cache is limited and the page was too large. [Options…] - or - * Firefox's network cache is limited and the page was evicted. [Options…] * Firefox did not automatically re-request the page because it was the result of a POST request (usually a non-idempotent form submission). * www.bankofamerica.com did not use a redirect, pushState, or replaceState to give Firefox an alternative, idempotent address to load instead.

(In reply to comment #221) > In the Reload case, we don't want to remove the ability to cancel. Should we > replace the dialog with an infobar or doorhanger when reloading? As I said, there appear to be a number of edge cases, of which this is one, which is why I feel we should split this off in to a separate bug.

Comment on attachment 539945 [details] [diff] [review] Updated for bitrot >we should reuse the text from the dialog, which focuses on the choice of >repeating what might be a transaction yeah, this part is key, because it's the actual choice that the user has to make (and hopefully, they understand the choice, but no guarantees on that, either way we need to try to ask). >But instead of a [Cancel] button I'd show a [Go back] button this sounds good, of course since this is a content area page the actual back button will be functional as well. >We could also have an expandable "Technical details" section that explains the >three factors that led to the page not being shown. It would explain which >parts are Firefox's fault and which parts are the web site's fault. Yeah, I'm fine with us providing information behind a collapsed disclosure section. Generally speaking though, there isn't really anything we can do to effectively move blame away from Firefox (aside from perhaps a very large icon for the site in the content area). We also shouldn't get our hopes up on this UI effectively convincing Web developers to create more usable sites, ultimately we end up taking the hit for not the Web not working.

Let's leave the "technical details" section for bug 493438.

yeah I would encourage us to break this apart to separate bugs, 225 comments is pretty much impossible to follow at this point.

(In reply to comment #224) > >we should reuse the text from the dialog, which focuses on the choice of > >repeating what might be a transaction > > yeah, this part is key, because it's the actual choice that the user has to > make (and hopefully, they understand the choice, but no guarantees on that, > either way we need to try to ask). Assuming this is the only sticking point for this part of the patch, I understand that we can't simply paste in the text from the dialog since it wouldn't apply exactly to an error page. Furthermore, the dialog still exists for now, which may confuse matters. Please could you therefore provide the exact text you would like to see.

Higher level question: can we just continue to go back until we actually are able to render a page?

Can we discuss that idea in bug 493437? :)

My most anyoning moment is at Firefox Startup. Normally this letter appear up to 7 times. In pages without any kind of tag saying "don use cache" ( comprobated, i control the server and the web application). the page must be catched, but i have "POSTDATA WARNING". At least one workaround mentioned was autoload a blank page with a button "repost the page" ( saying in addresbar wich site will be reposted).

(In reply to comment #227) > (In reply to comment #224) > > >we should reuse the text from the dialog, which focuses on the choice of > > >repeating what might be a transaction > > yeah, this part is key, because it's the actual choice that the user has to > > make (and hopefully, they understand the choice, but no guarantees on that, > > either way we need to try to ask). > Assuming this is the only sticking point for this part of the patch, I > understand that we can't simply paste in the text from the dialog since it > wouldn't apply exactly to an error page. Furthermore, the dialog still > exists for now, which may confuse matters. Please could you therefore > provide the exact text you would like to see. faaborg, ping?

(In reply to comment #230) > In pages without any kind of tag saying "don use cache" ( comprobated, i control the server and the web application). The thing is, Mozilla interprets "disable session history" into tags and circumstances which were not intended to mean that at all. It's a little bit like a banker who interprets "i want to have sex" into showing up in his room while wearing a nice uniform... Case in point: mailman installed over SSL. On some of its pages, mailman uses "Cache-Control: no-cache". The intent is not to disable history, but rather to make sure that when page is re-visited from _a_bookmark_, or by following _a_link_, it is refetched. And RFC 2616 Section 13.13 unambiguously says that cache controls should NOT apply to history. Now, if in addition to this the webmaster installs mailman over SSL, Firefox interprets the conjunction of both circumstances (Cache-Control: no-cache, and SSL) as to mean "disable history", even though none of the 2 people (software author and webmaster) who set these 2 settings independently from each other meant this. The solution to this issue should NOT be to dress up the failure in a nice UI, but to remove this non-RFC-compliant nonsense altogether. (The webmaster in the above example can fortunately remember that he has teeth, and just do: <Directory /usr/lib/cgi-bin/mailman/> Header always edit Cache-control no-cache "private, max-age=0" </Directory> ... but why should he have to resort to such hacks?)

Alain, that's bug 567365. We're trying to fix both problems.

Does fixing bug 567365 result in this bug being invalid? Sorry about all the confusion, it's hard to provide a ui-review+ to something that isn't a very good experience (Firefox telling you that it won't do the thing you want it to do).

(In reply to comment 234) > Does fixing bug 567365 result in this bug being invalid? Indeed, fixing bug 567365 (... and its companion, bug 261312) makes the condition where this dialog shows up go away in *most* cases. However, there will still be some rare cases where pages may be legitimately not be present in the history: - user manually did a Tools->ClearRecentHistory - user did lots of activity in other tabs before going back, causing the history entry to be evicted. - or there was a low memory condition cause the history to be pruned In these cases, the POSTDATA dialog would still be shown if the user tried to go back to such a page. So, to sum it up: fixing bug 567365 and bug 261312 would not make this bug invalid. However, it would make it much less painful.

Makes sense, and can we fix the remaining cases where the dialog would otherwise show up with bug 493437 ?

yes, but I think there should still be some kind of feedback that history pages were skipped. Maybe some small non-blocking indication in the status bar when it happens?

these types of indicators are remarkably ineffective at conveying any meaningful meaning to users (other examples include open search, mixed content ssl, update christmas tree in Firefox 1, rss). Probably the most effective indicator is going to be the users own memory of what pages they just interacted with. Also the entries will still be available in the recent back/forward history menu.

(In reply to comment #238) > Also the entries will still be available in the > recent back/forward history menu. So, given that there are always going to be cases where the user tries to go back to a page that we can't automatically regenerate, feel free to reassign this bug back to me once we have some approved wording for the error page.

or simply a blank page with the following text: The requested page: www.google.com cant be displayed without resend POSTDATA form with the following data: name="helo" pass=(hidden) bla bla bla =1 1)If you Do you want resend the form hit this "submit" button. 2)If you want resend allways for this site hit this "always" button. 3)if you never want be asked in the future hit "never" button. 4)If you decline, you only can view this blank page. Is simple, No extra notification required, no popup, non blocking issues. Clear information what user will do. The option 1 is very easy, is only hit the similar button that the user hit when the page was loaded in first time. The option 2 is the goal, let decide that google search page dont care if reloaded. Option 3 is the SECURE AND PARANOID banking user.

(In reply to comment #240) That's bug 569142, which was refused in bug 569142 comment 9. More things I would have liked to include in the error page are in bug 596142 comment 5.

Obviously, I meant bug 569142 comment 5.

If bug 569142 were fixed, having on the error page a button to go back to the nearest GET would almost satisfy bug 493437, and it would avoid confusing the user by skipping unexpectedly.

Shad's understanding of bug 569142 is different from mine. I understand it as asking for an error page on history navigation whenever a page isn't cached, even if it can be reloaded without resending POSTDATA. This bug, in contrast, is specific to cases that involve resending POSTDATA.

It doesn't occur to me to choose different behavior based on information not available to the user. When I hit "back," I'm not thinking of "go back to a POST result" or "go back to a GET result," I'm thinking "go back to the thing I saw before I saw this." I suppose you could do the confusing automatic reload with neither an explicit request or a notification (bug 666076) only for GET requests, and an error page (resembling bug 569142) only for POST requests, and it would be an improvement on the current behavior, but the overall behavior would still be inconsistent and confusing. You're right that while fixing bug 569142 would do the gist of what comment 240 suggests (likely excluding the per-site settings), it wouldn't restrict that behavior to POST results. That's bug 451250.

obviously this bug have 3 steps: 1)the uncached page with reason no cache tag or ssl pages 2)the uncached page WITHOUT reason line the pages without any no-cache, no-store tags 3)the euristic to difereciate automaticaly as possible 4)the UI to let user decide what to do. in comment#240 only wrote a temporary solution to the anyoning UI actual. The point 1) with no-cache there is not bug and the only turnaround that i think is save a "image"like jpg about what is your seen before close FF. The point 2) is a cache leaks and is a real bug. is possible the use the same turnaround of point 1, but real solution is caching the things cacheables. From comment #232 <Directory /usr/lib/cgi-bin/mailman/> Header always edit Cache-control no-cache "private, max-age=0" </Directory> My server dont have this in the configuration and equally FF didnt cache the dinamics pages. The point 3) there are an excelent heuristic placed in a comment that i cant find now ( #180 to #239) The point 4) #240 is a better idea that actual popup.

The heuristic you remember might be in comment 213 (solution 3), or comment 216.

(in reply to comment #246) > The point 1) with no-cache there is not bug Why do you think that case is not *a* bug? Or do you mean "not *this* bug" (in which case I'd agree, as this particular bug here is not about fixing the underlying problem, but rather about dressing it up...) > and the only turnaround that i think is save a "image"like jpg about what is your seen ... which would make both sides of the debate equally unhappy: * the users would not be able do anything worthwhile with the page, except maybe looking at it. Not even copy-paste would work * the "banks" would be unhappy too, because this might still expose bank statement data, or similar items > The point 2) is a cache leaks and is a real bug. Indeed, if the page is genuinely not in the history, and has been eliminated for a good reason (such as user-initiated clear-history, or a low-memory condition), Firefox does not have much choice except try to explain the situation to the user...

1) when a page is not cached with a good reason like bank. is good that the page dont be catched. ( the english is not my mother language) 2) 2.1)i develop a web application wrote from source line by line without toolkit. Is postdata based. (without any type of cache or expire tag) 2.2) I control full server ,located into my office and i am the root and i configure from scratch. (without any type of expire or cache tag) 2.3) Finally i use the application in the browser in my own PC . ( configured for keeping the cache, cookies or etc But when the browser is open appear 3 postdata warning ( one for each tab). The same result when i hit back button. Why?? if the page MUST BE CATCHED by FF!!!! This is a clear bug with no doubt.

Schmitz, please file a new bug with a testcase for #2, and CC me. Also, searh the web for "redirect after POST" and [1]. [1] http://en.wikipedia.org/wiki/Post/Redirect/Get

Comment on attachment 539945 [details] [diff] [review] Updated for bitrot This patch didn't belong here, so I moved it to bug 451250.

This bug also affects the fact that Firefox limits number of items in back/forward dropdown dialog to 15 (7 back and 7 forward), therefor if you submit 7 or more POST forms in a row you won't be able go back to the initial page via back/forward buttons without resubmitting one/more of the forms. Even if the annoying dialog box stays, and a user attempts move back/forward in history, by canceling the dialog box it should still move current position in session history with a "page expired" message, not stay at the same page before back/forward button clicked. I hate to point this out, but that's how Chrome and IE browsers handle such situations and if you once experience this you can't go back with FF nonsense.

Um...aperently in FF 10 it is different behaviour now - it shows "page is expired" page

Just checked in 13.0.1. Indeed, the wording of the annoying dialog has changed, but it lies, as it implies that the requested document is no longer available in Firefox's cache. But in reality it is, as going forward, checking "work offline" and going back again shows. The only thing that is preventing the page to be shown is a deliberate test that happens at display time which causes this annoying warning to be popped up in place of the page contents if certain http headers have been set. A more honest wording would be to say why Firefox refuses to show the content, which is actually still in the cache. And if no such explanation can be given, or if you feel that the true explanation may be too "shocking" for most Firefox users, then maybe this whole test should be removed, and pages in history always shown if the user asks for them.

I agree with alain knaff. I suspect that FF before to use cache try to look if the page is "updated", and in this moment find the postdata limitation. Konqueror have options: 1)Use cache allways 2)look if updated before use cache 3)never use cache Obviously i preffer 1.

That's obviously wrong. However, the error should not be a dialog but rather an error page. With a "show cached version" button if a cached version is available.

Or even better: have an about:config setting that makes it always show the history version when it is available. But if that is not possible, even having a button "show cached version" on the error page would be an improvement over the current situation. Also, the error page only shows up if it is the result of a POST. For a GET, the web page is fetched a second time, losing any unique content that it might have had before. That needs fixing too.

nag nag nag. seriously this bug exists since 2002? someone clearly likes it! However as an mmo addon developer who runs an auto-refresh script. the post data request really really screws this up. The end user does not care if it resends post data or forgets it. just so long as it reloads the web page. I think I could probably learn and create a hacked ff for people to at least compile before this bug will ever get fixed.

I think that adding a config option for this ought to be easy. Not assigning it to myself (yet) as I'm finding it hard to take time out to work on Bugzilla these days, but will be able to manage in a few weeks. I think this has already been hashed out here, but the *default* option should be security. You do not want to double-send a bank transaction. You do not want to duplicate a post on a forum or social networking site. POST data is for .. well ... *post* ing stuff. You don't always want to re-post. Permanent refreshable URLs are for GET, not POST. Sites like GitHub use an extra redirect to make the difference clear to the browser. I do think that users should get freedom in this, though. A config option seems great :)

(In reply to Manish Goregaokar [:manishearth] from comment #259) > I think that adding a config option for this ought to be easy. > > Not assigning it to myself (yet) as I'm finding it hard to take time out to > work on Bugzilla these days, but will be able to manage in a few weeks. On one of the many aliases of this bug, I've got a fix posted (albeit, without config option...) If I can dig up where, I'll post the link > > I think this has already been hashed out here, but the *default* option > should be security. This bug really doesn't really help security, as any person getting hold of your terminal can just do File->WorkOffline before going back to your banking transcripts. And this has been known since years already. This bug is doing *nothing* for security (even in the unlikely event that indeed somebody does his banking from a cybercafé, and gets up from his seat without closing his session first). > > You do not want to double-send a bank transaction. So you should fix this bug. This bug *causes* double-send of bank transactions. Without this bug, you would just view the contents of the transaction form *as sent*, rather than submitting a new copy. > > You do not want to duplicate a post on a forum or social networking site. Again, one more reason to fix this bug. > > POST data is for .. well ... *post* ing stuff. and? So how does this lead to "should not be stored in history"? And btw, the bug also applies to GET (it is merely less obvious in that case, but I've had a number of friend suggestions and similar items "vanish" from Facebook for me due to the GET version of this bug...) > You don't always want to > re-post. Permanent refreshable URLs are for GET, not POST. The question here is why does Firefox insist so much in "refreshing" if the user didn't ask it to. That's the bug, nothing else. "History" is just that: seeing the page how it *was* when requested, and *not* refetching a new copy. That is the bug that we want fixed here (ok, ok, this particular thread here is about rewording the dialog. But many of us really want to have this sow gone altogether, rather than just put under new makeup) > Sites like GitHub > use an extra redirect to make the difference clear to the browser. > > I do think that users should get freedom in this, though. A config option > seems great :) Indeed. Please can we at least configure this behavior?

I can think of number of reasons when resubmitting form is a welcome feature, fiddling around with settings to turn it on/off when needed is not very practical. However instead of showing modal dialog that halts entire browser it could show the cached page if available or "page expired" page, and also show a notification bar or such, with a button to resubmit.

New commenters should do as the Whiteboard says and read comment 112. When most of what you have to say is "me too" it's better to vote than to comment. If you're more interested in when reloading occurs than in the UI for reloading a POST result, this is not the bug you're looking for. Some recent commenters seem to want a fix to bug 596142 (don't automatically reload on back), which was refused in bug 597142 comment 9. After that was refused, I filed bug 666076 (inform user when automatically reloading). Some users clearly want the automatic reload behavior, see bug 762659 (going back sometimes doesn't reload). Many related bugs have been filed, the most thorough list of related bugs may be bug 569142 comment 14.

(In reply to Alain Knaff from comment #260) (I understood that we were talking about different things halfway through, go to the last reply to see what my "final" reply was, leaving the previous replies there just in case) > This bug really doesn't really help security, as any person getting hold of > your terminal can just do File->WorkOffline before going back to your > banking transcripts. And this has been known since years already. This bug > is doing *nothing* for security (even in the unlikely event that indeed > somebody does his banking from a cybercafé, and gets up from his seat > without closing his session first). I meant security from oneself. Security from messing up. Which is bad use of the word "security", I guess, but I hope you understand what I mean > So you should fix this bug. This bug *causes* double-send of bank > transactions. Without this bug, you would just view the contents of the > transaction form *as sent*, rather than submitting a new copy. Wait, what? The current behaviour is that on refreshing or backbuttoning a POSTDATA page, you are asked if you really want to submit. This is the dialog that people want to scrap. > and? So how does this lead to "should not be stored in history"? And btw, > the bug also applies to GET (it is merely less obvious in that case, but > I've had a number of friend suggestions and similar items "vanish" from > Facebook for me due to the GET version of this bug...) I don't have a problem with "should be stored in history". I have a problem with "remove the dialog", which was the primary feature request on some of the dupes to this one. > The question here is why does Firefox insist so much in "refreshing" if the > user didn't ask it to. That's the bug, nothing else. "History" is just that: > seeing the page how it *was* when requested, and *not* refetching a new > copy. That is the bug that we want fixed here (ok, ok, this particular > thread here is about rewording the dialog. But many of us really want to > have this sow gone altogether, rather than just put under new makeup) OK, now I get it. This thread has been the dupe of many various others, so it has grown to address various feature requests: - Get rid of the POSTDATA dialog for refresh/back and make resubmitting of POST the default - Get rid of the POSTDATA dialog for back and make the page remember the history - Give an option for getting rid of POSTDATA dialog that makes it always resubmit (bug 913907, which brought me here) and more To make my POV clear: What I'm addressing is making an option that lets users bypass the POSTDATA dialog that makes it always resubmit. My comment above was to say that I am against making "always resubmit" the default. I think the best way to solve this whole issue is to: - Have three options on the POSTDATA confirm: Resubmit, LoadFromHistory, and Cancel (someone think up better names please) - Have a config option to bypass the dialog with one of the first two options. Maybe have _two_ options, one for "back" and one for "refresh" - Discuss making bypass with LoadFromHistory the default (which is what I think people want) This seems to have been proposed in comment 112. I think. Probably should go through the entire thread sometime.

(In reply to neil@parkwaycc.co.uk from comment #239) > (In reply to comment #238) > > Also the entries will still be available in the > > recent back/forward history menu. > So, given that there are always going to be cases where the user tries to go > back to a page that we can't automatically regenerate, feel free to reassign > this bug back to me once we have some approved wording for the error page. Since this comment dated 2011-06-29, this bug is ASSIGNED to nobody@. I assume that this was an oversight. Neil, if it wasn't, set it back so. In reply to comment #263: In addition to this interesting technical discussion, I believe that it is important to couch the wording of the error page in language understandable to non-techies ("new makeup" or not, @Alain Knaff, comment #260). See an example of such wording in comment #74 (besides its usecase which spawned bug 493435).