Bug 74916

Summary:

Submitting a POST form with CTRL key is submitted with GET method

Product:

WebKit

Reporter:

yosin

Component:

Forms

Assignee:

yosin

Status:

NEW ---

Severity:

Normal

CC:

abarth, ap, darin, fishd, japhet, tkent, webkit.review.bot

Priority:

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

URL:

http://82.182.132.189/chromebug/bug1.shtml

Bug Depends on:

65111

Bug Blocks:

Attachments:

Description	Flags
Patch 1	none

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