Bug 31882 - [Chromium] Unable to repost form data by hitting reload
Summary: [Chromium] Unable to repost form data by hitting reload
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Darin Fisher (:fishd, Google)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-25 10:39 PST by Darin Fisher (:fishd, Google)
Modified: 2009-11-25 13:10 PST (History)
0 users

See Also:


Attachments
v1 patch (1.88 KB, patch)
2009-11-25 12:43 PST, Darin Fisher (:fishd, Google)
abarth: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Fisher (:fishd, Google) 2009-11-25 10:39:16 PST
[Chromium] Unable to repost form data by hitting reload

When the results of a form submission are not in the cache, the user
will see an error page indicating (with a scary warning) that they
would need to hit reload in order to see the page.  However, doing
so does not work.  Instead, Chrome issues a GET request to the URL.

Original bug report:
http://code.google.com/p/chromium/issues/detail?id=28678

Repro steps:
1- Load a page with a HTML form that does a POST
2- Submit the form
3- Go back
4- Clear your cache
5- Go forward
6- Observe the 'Confirm Form Resubmission' error page
7- Hit reload
8- Hit OK
9- Notice that the browser sends a GET instead of a POST
Comment 1 Darin Fisher (:fishd, Google) 2009-11-25 12:43:54 PST
Created attachment 43863 [details]
v1 patch

I went about writing a test for this, but sadly it can't work
in DRT or TestShell because neither loads error pages.  As a
result I have no way to simulate the steps from comment #0.
Enabling error pages would interfere with existing tests.

I could modify the layoutTestController to support an option
that would enable error pages, but that seems like a much
larger change that I'd rather defer to a separate patch.

(I'd like to land this so I can backport it to the Chrome 4
branch.)
Comment 2 Adam Barth 2009-11-25 12:50:46 PST
Comment on attachment 43863 [details]
v1 patch

This sounds reasonable.  Again, my confidence here is low.  Thanks for explaining why this is hard to test.

+ m_frame->loader()->activeDocumentLoader()->originalRequestCopy();

I'd prefer grabbing this object via m_frame->loader()->originalRequest(); but that's not essential.
Comment 3 Darin Fisher (:fishd, Google) 2009-11-25 12:55:41 PST
> I'd prefer grabbing this object via m_frame->loader()->originalRequest(); but
> that's not essential.

Oh, good call!  Thanks, I'll do that.
Comment 4 Darin Fisher (:fishd, Google) 2009-11-25 13:10:20 PST
Landed as http://trac.webkit.org/changeset/51394