[Webkit-unassigned] [Bug 44969] New: Track the right gesture state during the asynchronous form submission.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=44969

           Summary: Track the right gesture state during the asynchronous
                    form submission.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jnd at chromium.org
                CC: abarth at webkit.org, scarybeasts at gmail.com,
                    inferno at chromium.org


The following html can bypass chromium's popup blocker (You can also run the attached test case)
<form id="frm1" action="http://www.google.com" target="_blank"> 
<input type="submit" value="Submit"/> 
</form> 
<script> 
var form1 = document.getElementById('frm1');
form1.submit();
</script>

It's because WebKit can not provide correct gesture state during the asynchronous form submission.

In WebKit, when submitting a form, the FrameLoader::submitForm can get right gesture state to allow or disallow the popup form submission according to setting's m_javaScriptCanOpenWindowsAutomatically (See DOMWindow::allowPopUp) before scheduling the submission.
However, in chromium, we keep setting's m_javaScriptCanOpenWindowsAutomatically always true to always schedule any form submissions to allow the embedder (aka browser process) to make the decision by leveraging the chromium's popup blocker feature.

In WebKit, the actual form submission is asynchronous and executed in ScheduledFormSubmission::fire, so during the real executing time, we lost the right context to get the right correct gesture state.
In chromium, the RenderView::createView tried to call WebFrame::isProcessingUserGesture to get the gesture state when doing the real form submission, since we can not get the active(entered) frame in that time, the ScriptController::processingUserGesture returns true, so chromium thinks the popup submission is gesture-initiated, that is why the above test code bypasses chromium's popup blocker.

To fix this issue, we need to express the following logic:
if a submission was scheduled in response to a user gesture, set UserGestureIndicator's state to DefinitelyProcessingUserGesture when the submission timer fires; otherwise, set the state to DefinitelyNotProcessingUserGesture during the submission timer fires. (The solution actually is from Andy's comments in bug 34541).

The patch will look like

ScheduledFormSubmission::ScheduledFormSubmission(PassRefPtr<FormSubmission> submission, bool lockBackForwardList, bool duringLoad, bool wasUserGesture)
        : ScheduledNavigation(0, submission->lockHistory(), lockBackForwardList, duringLoad, true)
        , m_submission(submission)
        , m_haveToldClient(false)
        , m_wasUserGesture(wasUserGesture)

virtual void ScheduledFormSubmission::fire(Frame* frame)
{
     UserGestureIndicator gestureIndicator(m_wasUserGesture ? DefinitelyProcessingUserGesture : DefinitelyNotProcessingUserGesture);
     ...

@Adam, what do you think?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.