Bug 74916 - Submitting a POST form with CTRL key is submitted with GET method
Summary: Submitting a POST form with CTRL key is submitted with GET method
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: yosin
URL: http://82.182.132.189/chromebug/bug1....
Keywords:
Depends on: 65111
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-19 23:41 PST by yosin
Modified: 2012-04-20 13:42 PDT (History)
7 users (show)

See Also:


Attachments
Patch 1 (5.46 KB, patch)
2011-12-20 02:01 PST, yosin
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description yosin 2011-12-19 23:41:41 PST
Import from http://crbug.com/76665

What steps will reproduce the problem?
1. Create a HTML form with method POST with at least an input.
I attach an example file.
This script show the request method, show the request parameters and generate a simple form
2. Put this script or your own on your server (with a correct interpreter configuration)
3. Submit the form with a right click on submit button
4. It's OK the request method is POST and the form parameters are displayed
5. Now press and maintain CTRL key and right click on submit button
6. The Chrome browser open result in another tab but there is a bug :
The request method is GET (it should be POST) and the form parameters are lost

What is the expected result?

The expected result is 
6. The chrome browser open result in another tab
The request method is POST and the form parameters are displayed

What happens instead?
6. The Chrome browser open result in another tab but there is a bug :
The request method is GET (it should be POST) and the form parameters are lost
Comment 1 yosin 2011-12-20 01:54:17 PST
Fix wrong sample URL.
Comment 2 Kent Tamura 2011-12-20 01:56:56 PST
Is this a dupe of Bug 65111 ?
Comment 3 yosin 2011-12-20 02:01:12 PST
Created attachment 119997 [details]
Patch 1
Comment 4 yosin 2011-12-20 02:16:55 PST
This bug is part of BUG 65111. My patch fixes CTRL+Submit issue for Chromium. Once other ports implement FrameLoaderClient::shouldPostToNewWindow, BUG 65111 should be fixed.
Comment 5 Alexey Proskuryakov 2011-12-20 16:22:36 PST
Please don't put [chromium] prefix on bugs that change cross-platform behavior. Such bugs should not be hidden from the view of core developers.

I'm also confused about the relationship between this bug and bug 65111.

+    } else if (m_client->shouldPostToNewWindow(action))
+            policyChecker()->checkNewWindowPolicy(action, FrameLoader::callContinueLoadAfterNewWindowPolicy, workingResourceRequest, formState.release(), frameName, this);

This is rather strange code. How many authorities need to be asked to get a simple decision like this one? Seems like policyChecker shouldn't need to be double checked.
Comment 6 yosin 2011-12-20 20:13:32 PST
This patch provides two things:
1. New framework for CTRL+Submit with new API in FrameLoaderClient
2. API implementation for Chromium

And this patch doesn't fix BUG-65111 because of it is for Mac platform.

I think we want to call PolicyChecker::checkNewWindowPolicy for both web author specified new window case, e.g. frame[@target="_balnk"], and user driven case, e.g. Ctrl+Button.

FrameClient::shouldPostToNewWindow provides user's intention. PolicyChecker::checkNewWindowPolicy enforces environment intention.
Comment 7 Eric Seidel (no email) 2012-02-10 10:20:07 PST
Comment on attachment 119997 [details]
Patch 1

How do we test this?
Comment 8 Kent Tamura 2012-02-13 19:17:34 PST
(In reply to comment #7)
> (From update of attachment 119997 [details])
> How do we test this?

Probably we can test this by layoutTestController.setCanOpenWindows(true) and click by eventSender.
Comment 9 yosin 2012-02-16 00:25:54 PST
I tried to write LayoutTest. It seems DumpRenderTree doesn't open new window for Ctrl+Submit. I checked history.length and its value is "2" instead of "1".

Actual output of this test is:
method=POST POST:q=foo history.length=2 END

Expected out put is
method=POST POST:q=foo history.length=1 END

So, we need to do manual test with following form:
<form method="post" action="http://search.yahoo.com">
<input name="q" value="foo">
<input type="submit" value="Go">
</form>

On Chrome M18, behaviors are
Submit Same window, query field contains "foo"
Ctrl+Submit New tab, query field is empty
Shift+Submit New window, Query field is empty


== form-ctrl-submit.html"
<head>
<script>
function start() {
    if (window.layoutTestController) {
        testIt();
    }
}

function testIt() {
    layoutTestController.setCanOpenWindows();
    layoutTestController.dumpAsText();
    layoutTestController.dumpChildFramesAsText();

    // Submit form
    var submit = document.getElementById("submit1");
    eventSender.mouseMoveTo(submit.offsetLeft + 3, submit.offsetTop + 3);
    eventSender.mouseDown(0);
    eventSender.mouseUp(0, ["ctrlKey"]);

    layoutTestController.waitUntilDone();
    layoutTestController.setCloseRemainingWindowsWhenComplete()
}
</script>
<head>
<body onload="start();">
<form id="form1" method="post" action="./resources/form-dump.php">
    <input type="hidden" name="q" value="foo">
    <input id="submit1" type="submit" value="Go">
</form>
</body>

== form-dump.php ==
<?
printf("method=%s\n", $_SERVER['REQUEST_METHOD']);
foreach ($_GET as $key => $val) {
  printf("GET:%s=%s\n", $key, $val);
}

foreach ($_POST as $key => $val) {
  printf("POST:%s=%s\n", $key, $val);
}
?>
<script>
document.write("history.length=" + window.history.length);
layoutTestController.notifyDone();
</script>
END