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

RESOLVED FIXED

Status

()

RESOLVED FIXED
11 years ago
7 years ago

People

(Reporter: yp_mozilla, Assigned: bzbarsky)

Tracking

Trunk
Points:
---
Bug Flags:
blocking1.9 -
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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.
(Reporter)

Updated

11 years ago
OS: Mac OS X → All
Hardware: Macintosh → All
Version: unspecified → Trunk

Comment 1

11 years ago
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.
Status: UNCONFIRMED → NEW
Component: General → History: Session
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → history.session
(Assignee)

Comment 2

11 years ago
How nice.  This has been broken ever since bug 180598 landed.
Blocks: 180598
(Assignee)

Comment 3

11 years ago
Created attachment 304595 [details] [diff] [review]
Fix
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #304595 - Flags: superreview?(cbiesinger)
Attachment #304595 - Flags: review?(cbiesinger)
(Assignee)

Updated

11 years ago
Summary: HTTP form is post again without notice under rare occasions → [FIX]HTTP form is post again without notice under rare occasions

Updated

11 years ago
Flags: blocking1.9?
Once reviewed, just ask for approval.  Won't block on this as it's not a regression.
Flags: blocking1.9? → blocking1.9-
Attachment #304595 - Flags: superreview?(cbiesinger)
Attachment #304595 - Flags: superreview+
Attachment #304595 - Flags: review?(cbiesinger)
Attachment #304595 - Flags: review+
(Assignee)

Comment 5

11 years ago
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
Attachment #304595 - Flags: approval1.9?
Comment on attachment 304595 [details] [diff] [review]
Fix

a1.9+=damons
Attachment #304595 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 7

11 years ago
Comment on attachment 304595 [details] [diff] [review]
Fix

Would be nice to just get this in for b4.  This should be pretty safe.
Attachment #304595 - Flags: approval1.9b4?
Comment on attachment 304595 [details] [diff] [review]
Fix

a1.9b4=beltzner
Attachment #304595 - Flags: approval1.9b4? → approval1.9b4+
(Assignee)

Comment 9

11 years ago
Fixed for 1.9b4.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
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!
(Assignee)

Comment 11

11 years ago
I commented in bug 235853.

Updated

10 years ago
Component: History: Session → Document Navigation
QA Contact: history.session → docshell

Updated

7 years ago
Depends on: 685782
(Assignee)

Updated

7 years ago
No longer depends on: 685782
You need to log in before you can comment on or make changes to this bug.