User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008010704 Minefield/3.0b3pre After a form post has been done and the browser's location is changed by javascript to append an anchor to the URL (for example: the form's action is http://example.com/page.php and javascript rewrites it to http://example.com/page.php#top after the form post), now if the user visits some specific websites and then use the browser's back button to go back to the page with the anchor as the URL, the browser will post the form again without notifying the user. I've written a PHP script to demonstrate this bug, it can be found at http://ypwong.org/test_firefox_bug.txt. Reproducible: Always Steps to Reproduce: 1. Go to http://ypwong.org/test_firefox_bug.php 2. Press the "Submit" button on the page. 3. Now the page will show the time when the server receives the HTTP POST. At the same time, the URL is appended with "#something" by javascript. 4. Now you need to visit some other webpages. The sequences of what webpages to visit have been mentioned on the page, which are: maps.google.com -> click the "seattle to 98109" link -> click "Take Public Transit" link -> click the "Drive There" link 5. Use the browser's back button to go back to http://ypwong.org/test_firefox_bug.php#something 6. Now you'll see that another form post is done again.

Confirm this using Mozilla/5.0 (X11; U; SunOS i86pc; zh-CN; rv:1.9b3) Gecko/2008021410 Firefox/3.0b3. This could cause the re-post of the information.

How nice. This has been broken ever since bug 180598 landed.

Once reviewed, just ask for approval. Won't block on this as it's not a regression.

Comment on attachment 304595 [details] [diff] [review] Fix This is a very safe fix. Just makes sure to copy the cache key so we don't silently repost

Comment on attachment 304595 [details] [diff] [review] Fix a1.9+=damons

Comment on attachment 304595 [details] [diff] [review] Fix Would be nice to just get this in for b4. This should be pretty safe.

Comment on attachment 304595 [details] [diff] [review] Fix a1.9b4=beltzner

Fixed for 1.9b4.

A change to do PAC resolution asynchronously (bug 235953) caused this test to fail, in that the test posted a confirmation dialog, which hung the test -- can anyone help me understand how PAC would interact here? We'd really really like to get PAC non-blocking before beta5. I can offer candy!

I commented in bug 235853.