413310 - [FIX]HTTP form is post again without notice under rare occasions

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Anthony Wong]

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.

Comment 1

[Alfred Peng]

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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

Comment 4

[Damon Sicore (:damons)]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

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 6

[Damon Sicore (:damons)]

Comment on attachment 304595 [details] [diff] [review]
Fix

a1.9+=damons

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 304595 [details] [diff] [review]
Fix

Would be nice to just get this in for b4.  This should be pretty safe.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 304595 [details] [diff] [review]
Fix

a1.9b4=beltzner

Comment 9

[Boris Zbarsky [:bzbarsky]]

Fixed for 1.9b4.

Comment 10

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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!

Comment 11

[Boris Zbarsky [:bzbarsky]]

I commented in bug 235853.