[Webkit-unassigned] [Bug 42827] New: Use the js-execute-active(entered) Frame to check the user gesture of page instead of checking the top frame

[bugzilla-daemon at webkit.org]

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

           Summary: Use the js-execute-active(entered) Frame to check the
                    user gesture of page instead of checking the top frame
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
               URL: http://watchthesimpsons.com/
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Frames
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jnd at chromium.org
                CC: darin at apple.com, abarth at webkit.org, yurys at chromium.org


Created an attachment (id=62300)
 --> (https://bugs.webkit.org/attachment.cgi?id=62300)
test case

On chromium with enabling popup blocker, http://watchthesimpsons.com/ bypassed the popup blocker [firefox does block it]

The attachment is the test case to reproduce this issue.

The following is my investigation.

The window.open is called in the iframe without user-initiated.

On Safari, it uses WebCore::Setting::m_javaScriptCanOpenWindowsAutomatically flag to do the popup blocker, when enabling popup blocker, m_javaScriptCanOpenWindowsAutomatically is set to true, so DOMWindow::allowPopUp returns false to deny to open the window. So this issue can not be reproduced on Safari.
On Chromium, the flag WebCore::Setting::m_javaScriptCanOpenWindowsAutomatically is always true, the request of opening window is always passed to browser process to do the popup check. When enabling chromium's popup blocker, only user-initiated open request can be allowed.

In this issue, the window.open was called in the iframe without user-initiated. but when calling WebFrame::isProcessingUserGesture in RenderView::createView, in the function FrameLoader::isProcessingUserGesture, it checked top frame's user gesture status, since there was no script executed in top frame, ScriptController::processingUserGesture assumed it's user-initiated (line 166-167). Then chromium treated the opening window request is legal and granted the opening.
I think the current behavior in the frameloader is wrong, we should check the js-execute-active frame (entered frame in V8) instead of the top frame since the script execution can be initiated in any frame not only the top frame. Please refer to the right implementation of the WebCore::processingUserGesture (both JS and V8 version)

The issue does not reproduce on Chromium v5 stable and popup is blocked, but reproducible on the latest Chrome trunk. After digging in the WebKit trunk, I found before r62380 (http://trac.webkit.org/changeset/62380), the function ScriptController::processingUserGesture did only check the active frame's user gesture status not current frame, so even we call the function to check the top frame's user gesture status, it still can returned the right status. But just because the function tested if there are any Frame on the stack where JS is executing, it caused bug https://bugs.webkit.org/show_bug.cgi?id=41511, that's why Yury changed it in r62380.


My solution is adding a function in ScriptController to get the active/entered frame, so the function FrameLoader::isProcessingUserGesture can correctly test the user gesture status of the page.

Any comments?

@Darin, your are the author of FrameLoader(according to http://trac.webkit.org/changeset/17652/), would you please give your comments?

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