This is because we don't cache form submissions yes and must reload. Firefox caches 
form submissions.

Is there a reason why we don't cache it or is it just because we haven't gotten 
around to it?

Darin answered my last question on the dev mailing list:

"Most browsers implement some form of cache to allow them to re-render the output of 
the form post without actually repeating the form post.  Of course, said cache 
sometimes lacks the required data, so all browsers will end up sometimes having to 
ask you to reload.  We have not yet implemented such a cache for Chrome, which 
explains why you always see this error page prompting you to reload."

Very annoying

I hate Chrome because of this issue. 

I'm sorry, but I agree. I use Chrome and other Google products at work all day, and 
this feature alone makes it very difficult to perform my job.

<b> Hey I found a fix for this !! Google Gears. 

http://gears.google.com/

More Information!!  http://code.google.com/apis/gears/

"Cache and serve application resources (HTML, JavaScript, images, etc.) locally"

Two times while filling out a survey I lost a long post due to accidentally pressing 
the Back key on my laptop, which is next to the arrow keys. Raising priority on this 
one to P1 because this involves data loss and is extremely frustrating. This is my 
number 1 annoyance with Chrome and according to friends and what I've heard there are 
lots of users that share that view.

(No comment was entered for this change.)

bit of a background, this is by far the most annoying usage problem of Chrome. I
wonder how come usability tests didn't point out this issue yet.

So let us get this straight: Chrome does cache the form data; same does Firefox.
However when clicking the back button, Firefox serves you a cached version of the
page, with the option that if you click Reload, that the <form> elements get
"re-POST-ed". Chrome doesn't cache the result page, just the <form> elements, and
requires you to "re-POST" the form in order to see the result page; which in such a
case isn't a (back) history page anymore, but a fresh page since you just forced the
repost action. 

On the other hand Chrome caches greedy all it can find (about:cache), but not the
actual "work-path"? WTF?

I vote to higher the priority of this ticket.
All the people I know that use Chrome also complain about this issue.
Guys, please let's fix it.

I also find this a nightmare, enough that I have sopped using Chrome until it's 
fixed, otherwise an awesome browser!!

Yes, this issue needs fixing!

The link http://gears.google.com does not point to an installer for Google Gears, but 
rather gives a brief description of it. The link http://code.google.com/apis/gears/ 
has a link titled "install" which just points back to the other.  Is this perhaps a 
temporary bug?  Anyway, if anyone successfully installed Google Gears, does it even 
solve the "Confirm Form Resubmission" problem ("CFR")?

There is widespread reporting of this bug spanning over the past four months, and the 
lack of change is disturbing.  Is there any evidence anywhere that Google is doing 
ANYTHING about this?!?!  Have they even said so much as they refuse to fix it?

COME ON GOOGLE!!!  SAY SOMETHING!!!

I fully agree. I find myself shouting all kinds of obscenities when ever I see that 
irritating confirm resubmission page. Can't it at least have an option to just 
resubmit it without asking for confirmation? Like some setting buried in Options > 
Under the Hood? I REALLY HATE that page but freaking love the rest of the browser. 
Bravo so far on the beta other that what has become the most annoying browser defect 
I have experienced.

I strugle to keep liking Chrome even tho this damn message allways keep showing when 
I'm browsing.

mal7798: "Gears" did not reslove the issue even after a reboot.

For those looking for a quick workaround: try adding  -disable-prompt-on-repost  to 
the shortcut target used to start Chrome.

The newer, non-beta Chrome, appears to have F5 as a toggle for this behavior.

Thank you dhhwai, but as you can see above, this has not worked for many of us.  I've 
tried the following variations at least:

"...chrome.exe" -disable-prompt-on-repost
"...chrome.exe" --disable-prompt-on-repost
"...chrome.exe" "-disable-prompt-on-repost"
"...chrome.exe" "--disable-prompt-on-repost"
"...chrome.exe" -"disable-prompt-on-repost"
"...chrome.exe" --"disable-prompt-on-repost"
"...chrome.exe -disable-prompt-on-repost"
"...chrome.exe --disable-prompt-on-repost"

and probably more, and this does not work (the "..." is the rest of the address).  Is 
there an obvious error I am making?  And thank you, lederermc, but the F5 tip does not 
work either.

I agree wit mal7798:

(1) F5 doesn't work
(2) shortcut switch doesn't work
(3) the message is very annoying

This irritation is very real and continues.  I just found this page today, and I 
can't believe that people are still waiting to hear something from the Google folks.  
What on earth is going on here?  I have a major software membership on the web that 
is integral to my job, and this lack of being able to link to the previous page, as 
we do in IE or Firefox, etc., is just plain disgusting.

Yeah, we hear you all. And in fact, Anthony has been looking into this even though 
the status doesn't reflect that. I'm told this is not trivial to implement, though.

This is super annoying and probably leads to attrition so I strongly feel Milestone-X 
is the wrong classification here. Hopefully, I won't get overruled - this is my 
number one gripe with Chrome at the moment.

One and only reason I still have Firefox installed is this bug.  I won't do any 
serious form submissions in Chrome because of this.  By serious I mean shopping 
carts, web banking, and much work related Intranet stuff.  

Problem also occurs on sites with no login, no forms, just text, such as product 
reviews. Couple screens deep then CFR going back. Perhaps these sites look like forms 
to Chrome and thus get handled that way, but in any case it is very annoying. Great 
browser, but Firefox until it's fixed.

In the hopes that Google staff actually read these posts, i submit the following:
1. Will the "Confirm Form Resubmission" issue be resolved?
2. Are you CURRENTLY working on a solution?
3. Assuming you are working on it, please share an ETA with us loyal Googsters.
4. If a resolution is not somewhere in the offing, PLEASE let us know so we may 
proceed appropriately.

Thank you.

I am still working on it off and on as a part time task in addition to other 
projects, but as Finnur noted it is a little tricky to solve properly. We understand 
this is a very annoying bug, and I hope we'll be able to have a fix sometime in Q1 
this year. If anyone is interested in collaborating or sending patches to help let us 
know via the discussion group or IRC channel (find these at http://dev.chromium.org). 

Could someone please go into a little detail as to why this is so difficult to 
resolve?  It has not to my knowledge been an issue with IE or Firefox, so why with 
Chrome?  Is this more of a technical or a legal issue, or something else?  Clicking 
the reload button seems to get the page to where I want it, so could it be set to 
simply reload the page automatically whenever that dialog is cued to display (I 
suppose with an option to shut it off for those who inexplicably actually want/need it 
to display).

The dialog has so far actually been a misnomer for me, as these "forms" whose 
resubmissions I have been prompted to confirm have yet to include an actual form, but  
have all been merely search results.  If the difficulties of repairing this stem from  
fear that users will be accidentally submitting duplicate credit card transactions, 
please give us more credit.  I would like to think that we Google Chrome users are a 
little smarter than the average web surfer, and thus we're not the type who are going 
to frequently be absentmindedly paging back after making online payments.  And I am 
willing to bet that most of us would be willing to take the risk of doing that in 
order to have this error resolved.

(No comment was entered for this change.)

The difficulty is purely technical. It's due to a lot of complexity in the forward/back 
navigation code in FrameLoader.cpp, the fact that Chromium uses a different cache 
implementation from WebKit (ours uses IPC between the browser and renderer processes, 
etc.), and a subtle race condition between the time we ask the cache if it contains a copy 
of the form post result and when we actually fetch it (when it could then be missing). 

See https://bugs.webkit.org/show_bug.cgi?id=22194 for some more details on related changes 
in WebKit. 

We do understand that many people are eager to have this fixed.

I am sure everyone appreciates the efforts and knowing as much about what is being 
done as possible.  If Google Chrome wasn't such an excellent browser, people would be 
more likely to abandon it rather than eagerly--and of course impatiently--await this 
fix.  The fact that people seem relentless about this bug probably says more good 
things about the browser than bad.

oh my, it's so very frustrating! this and some auto form (and addons,I really like 
Cooliris. And I can't belive that syncing my google bookmarks with chrome bookmarks 
isn't a part of the browser) are the only reasons I keep FF. I dont want to keep it, 
it's such a hog compared with chrome.

I love chrome so I keep it as my browser, but I do entry at work, so this obnoxious 
fault a LOT. I have to stop my work flow every time this message shows up. Work-work-
work-work-STOP....reload...wait....work-work-work-work

We maintain an application that runs across multiple frames. I suspect that the
problem I describe here would be the same if it were using multiple tabs or multiple
windows. 

The POST (for a search) is done in one frame and the search result is displayed in
another. If the user select one of the search results (an individual record), it is
displayed in the parent of these two frames, thus replacing on screen both the search
parameters and search results. If we click back once the record is shown, it should
get him back to the search parameters and search results. It does so fine with IE &
Firefox, but with Chrome it only works if GET is used instead of POST.

What happens on the "back" event, is that my page that handles the form gets called,
but without any POST data. Chrome doesn't even prompt the user with the (annoying)
Confirm Form Resubmission message. This page has no way of knowing who called it and
with what values and thus returns an error.

While I understand that it may be nice to always have up-to-date information on a
browser, I am surprised that clicking "back" in Chrome doesn't simply redisplay the
same page as was already shown and which should be buffered by the browser, like
other browsers are doing. This puts unnecessary extra strain on the servers
(especially for complex searches) and throws-off page usage statistics. 

Is there a way to force Chrome to use a buffered page instead of a reload on "back"?
Will the POST buffer discussed in this thread work in situations like mine where the
POST is done in a different frame/window/tab as the result is shown? 

It's great to see that this issue has been assigned a top priority. Is there an
estimate as to when a solution will be released?

I just noticed a related issue: if you have a page resulting from a POST sitting in a
frame and you "Open in new tab" or "Open in new window", the new tab (or window) is
opened but without any POST data. Any web page that relies on POST data can cause
this problem.

Re-summarizing to reflect what this bug is about.

Yeah, horrible HORRIBLE function. I really hope they do something about this soon

I am just checking on the latest progress on this bug, since it has been nearly a 
month since the last post.

Google: why are you making this more complex than it needs to be? i can go "back" on 
NON-FORM pages without reloading. how? obviously, non-form pages are being remembered 
locally in some way. just do the same thing with form pages as you're doing with NON-
form pages!

@johnywhy
You can go back on non-form pages without reloading because the HTML & data is stored 
in cache to begin with. 

With user-entered form data, that never gets stored anywhere. The problem is storing 
the information as the user enters it. This includes not just text, but also radio-
buttons, checkboxes, drop-down lists, etc.

that does not sound correct to me, because it is NOT the FORM we are going back to 
(with textboxes and user-entered text), but rather the RESULTS of the form we are 
going back to, which does not contain any user-entered information.

hm, ok, weird, i deleted a post on this thread. then i closed the tab. then i 
reopened the tab with SHIFT-CTRL-T. then i clicked back, and lo and behold, there was 
the post i had deleted. how does that happen?

next, i set chrome to "restore the pages that were open last" in chrome options. then i 
deleted a post on this thread, and exited chrome completely. then i relaunched chrome, 
hit "back" on this page, and there was the post i had deleted. 

this stuff is getting stored or 'cached' somehow by chrome. they should apply the same 
technique to form-results pages. like, behind the scenes, trick chrome's 'back' 
function into thinking that form results are just a normal web-page.

Sorry guys, but you have really dropped the ball on this.

asargent is not working on this. We need a new owner.

This is not going to get fixed in time for a Beta push. We still need to do this 
before the next Stable update.

Looking for a new owner.

Ben suggested Scott.

This isn't up in the UI layer, rather it's in our page cache and/or WebKit. Antony 
has done a bit of investigation into this, but moved onto something else. Darin has 
also thought about it, and I was told Dimitri may be interested. Irregardless, I'm 
not the right person so passing back to the great unowned pile.

Moving this up to a P1 in anticipation of the next Beta release.

It's a bit late to consider this for 2.0, so I'm pushing to 2.1. If anyone on the cc 
list has the time and thinks it isn't that risky, please pipe up.

(No comment was entered for this change.)

(No comment was entered for this change.)

I've got a working prototype that I'm polishing for review.  The WebKit part has 
already landed here:  https://bugs.webkit.org/show_bug.cgi?id=24741

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=12374 

------------------------------------------------------------------------
r12374 | darin@chromium.org | 2009-03-24 11:20:06 -0700 (Tue, 24 Mar 2009) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/upload_data.h?r1=12374&r2=12373
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache.cc?r1=12374&r2=12373
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache.h?r1=12374&r2=12373
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache_unittest.cc?r1=12374&r2=12373
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_request_info.h?r1=12374&r2=12373

Net module changes to support caching responses to a POST request.

The solution is to add a user-defined identifier to UploadData.  If that identifier is set, and if the request method is POST, then HttpCache will enable caching for the response.  (The cache key will be a composition of the identifier and the URL.)  A subsequent POST request to the same URL with the same identifier will "hit" the previously generated cache entry.  Reuse from the cache is subject to all of the standard rules.

BUG=2636
R=wtc

Review URL: http://codereview.chromium.org/52028
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=12485 

------------------------------------------------------------------------
r12485 | darin@chromium.org | 2009-03-25 12:55:08 -0700 (Wed, 25 Mar 2009) | 19 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc?r1=12485&r2=12484
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/render_messages.h?r1=12485&r2=12484
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/resource_dispatcher.cc?r1=12485&r2=12484
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/glue_serialize.cc?r1=12485&r2=12484
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/resource_handle_impl.cc?r1=12485&r2=12484
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/resource_loader_bridge.h?r1=12485&r2=12484
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/weburlrequest_impl.cc?r1=12485&r2=12484
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/test_shell/simple_resource_loader_bridge.cc?r1=12485&r2=12484

Chrome changes to support cached form submissions.

The solution is to add a user-defined identifier to UploadData.
If that identifier is set, and if the request method is POST,
then HttpCache will enable caching for the response.  (The cache
key will be a composition of the identifier and the URL.)  A
subsequent POST request to the same URL with the same identifier
will "hit" the previously generated cache entry.  Reuse from the
cache is subject to all of the standard rules.

For reference, here are the corresponding net changes:
http://codereview.chromium.org/52028

Here are the corresponding WebKit changes:
http://trac.webkit.org/changeset/41919

BUG=2636
R=sky
Review URL: http://codereview.chromium.org/52040
------------------------------------------------------------------------

(No comment was entered for this change.)

 Issue 8976  has been merged into this issue.

 Issue 3840  has been merged into this issue.

how is this fixed ?
I am on the beta branch & still have this problem !
(I hate it !)

David Hartley, I believe Fixed means it is fixed on the current test builds (hourly 
builds), or possibly the Dev branch build, but not the Beta build.

thanks Chris !
I've just updated to dev branch & v.2.0.171.0
I'm looking forward to the possibility of not seeing this bug again ;-)

I'm not sure we have cut a Dev build that includes this fix. In fact, I think we 
haven't - but you are on the right channel; this is where the fix shows up first. 
Hopefully we'll get a new Dev build soon.

You can monitor this page for notifications of new releases:
http://googlechromereleases.blogspot.com/

Tested in 2.0.172.2 (which lists this bug as fixed) and this is still broken.  My bug 
report was merged with this one but I have an extremely simple test.  Go here and 
follow the instructions.

http://www.uni-nets.com/chrometests/brokenforms.php

Actually I think my bug report was erroneously merged with this one.  My bug manifests 
in this case when you press back a second time and don't return to the homepage.  My 
"brokenforms" link is a much more simple test.

Just downloaded the unofficial chromium build for mac osx, and the bug seems to be 
fixed.

I tried out jmyoder's brokenforms.php link using the beta version of Chrome 
(2.0.169.1), and there's still a bug. I click the Back button once, and it stays on 
the same page. I click on the back button again, and it goes back two pages, the page 
before the form. "Page 2 says, Ok, now go back and this text should go away, but it 
won't". In Internet Explorer, the text goes away because it goes back to page 1. In 
Chrome, it doesn't go away because it stays on page 2.

i am runing the 2.0.170.0 (11578) of Chromium and the repost enaoyande is still 
there... anyone knows a way to get rid of that ?

Would seeting up some type of Proxy server help go arround this message ?

@ericterii,
this fix is included in Chrome 2.0.172.2 (Dev), which is also included in Chrome 2.0.172.6 (Beta)
See:  http://googlechromereleases.blogspot.com/2009/04/dev-update-fixes-right-click-copy-and.html

Please test again after updating to the latest Chrome from Wrench menu > About Google Chrome

I still have the problem using Google Chrome 2.0.172.8. I used http://www.uni-
nets.com/chrometests/brokenforms.php as a test. I entered a word in the form on page 1 
and went to page 2. The Back button wouldn't let me go to page 1. I had to go to the 
page before page 1 with a second click of the Back button and then forward to page 1 
with the Forward button. Then I clicked the Forward button to go to page 2 and I see 
"Confirm Form Resubmission".

I really hate to see this bug keep destroying my work flow. I had to go back to using 
Firefox because of this bug. Why isn't this fixed yet? is there any plan to have it 
fixed soon? It's unbelievable that it hasn't been fixed by now

According to RFC 2616 Section 9.5:  " Responses to [POST] method are not cacheable,
unless the response includes appropriate Cache-Control or Expires header fields."

This means: Browser should cache result page from a form that uses POST method for a
duration of a browser session ONLY if web developer adds appropriate cache control
header (e.g. Cache-Control: max-age=1000).  If form used GET method, browser should
cache the results page UNLESS the application developer adds a negative cache control
header (e.g. Cache-Control: no-cache).

For back button to behave as expected both web developers and browser developers have
to do the right thing.  In the example site given at the top of this tread, the web
developer is responsible for the caching (back button) problem:  they should have
used GET method in that search form - it's just a text field so there is no reason to
use POST.

In some other application (e.g. where you have a TEXTAREA with 4kb+ of text) using
POST method form is the only option.  In those cases the browser engineers have to do
the right thing and enable response caching -- provided that the web developer
supplies appropriate cache control header.

Incidentally, Firefox 3.0.10 suffers from same bug/"feature"/problem. Try back button
to a results page from POST method and FireFox pops up a dialog under all
circumstances.  "To display this page, Firefox must send information that will repeat
any action (such as a search or order confirmation) that was performed earlier."  I'm
no fan of IE but currently only IE caches post request responses.

 I stand corrected about Firefox.  The back button problems I was experiencing were
caused by a firefox extension.  Upon updating this extension the problem was solved,
and firefox handled caching of POST request responses as one would expect. 

Re-opening based on comment 80.

OK, here's the deal:

http://www.uni-nets.com/chrometests/brokenforms.php is a very special test case.  
That URL supports both GET and POST.  Initially, when you just load that URL, the 
browser does a GET.  Then when you submit the form, the browser does a POST to the 
same URL.  Hitting back, goes back to the page that was fetched using GET.  Hitting 
forward, should load the POSTed page from cache, but it does not.  That seems to be a 
new bug, possibly related to WebKit getting confused by the URLs being the same.

In cases where the two URLs differ, I believe that our current solution works just 
fine.  This page http://www.cs.tut.fi/~jkorpela/forms/form1.html does not have the 
bug.

So, I am going to close this bug as FIXED in favor of opening a new bug for the 
remaining issue.  If you find other edge cases like this, please file a new bug.  
Thanks!

FYI: I filed  issue 11627  for http://www.uni-nets.com/chrometests/brokenforms.php

How is this fixed? I'm on 3.0.195.6 and I still have to resubmit my search data when i 
hit the back button. My specific example is when searching an online library catalog. I 
enter my data, get a list of results and then follow the link to one of the results. I 
then hit the back button to return to the results as there is no "return to results" 
link. When I hit the back button I invariably get the Form Resubmission error page. 

I just lost about an hours work due to this bug. Not only did it not save my submitted 
form when I clicked back, but it also saved OVER the stuff that was already there with 
a blank form without me submitting anything.

Really annoying bug.

I know it is partially my fault for working in a browser, which is not the best idea I 
have ever had and won't be doing again. But please fix it anyway.

Hey---I just installed Chrome...and frankly am impressded with the speed and 
simplicity of it...Hats off to Google.

BUT, for me, Chrome is a TOOL, not an end....

This thread is now over a year old...OVER A YEAR....and there is STILL no resolution 
to this issue.  

Are you kidding me?  If a major product offering I created at work had a bug and we 
were getting these types of complaints from our customers--"we are not using your 
product because of this bug," my boss would be thinking in terms of hours and days 
NOT months and years for a fix.

Either fix it or admit its not a priority so decisions can be made by YOUR customers.  
Bet your advertisers are interested

Good luck

Status: Fixed

But, bug is still here! Every time when I go back (& confirm resubmission) from 
particular item to whole search list I finish with empty search page (or error).

Very annoying!

Even I have been seeing the same issue intermittently with latest stable version 
3.0.195.33. 

Hello, anybody there? :)

I don't think it is productive to spam over 90 people with your complaint about a fix 
not working. 

If this is not working for you then file a new bug: http://new.crbug.com, and give 
step-by-step instructions on how to reproduce the issue you are seeing and what OS you 
have.