Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2553783003:
Don't consume user gesture in RenderFrameProxy::navigate. (Closed)
|
Created:
4 years ago by alexmos Modified:
4 years ago CC:
chromium-reviews, nasko+codewatch_chromium.org, mlamouri+watch-content_chromium.org, jam, darin-cc_chromium.org, creis+watch_chromium.org, site-isolation-reviews_chromium.org Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionDon't consume user gesture in RenderFrameProxy::navigate.
RenderFrameProxy::navigate should never result in opening a new tab
(see RenderFrameProxyHost::OnOpenURL, which DCHECKs that the
disposition is for a current tab). Yet, it currently unconditionally
consumes the user gesture. This leads to problems if a frame tries to
later consume the gesture, e.g., by opening a popup, after navigating
a remote frame. This CL removes that problematic consumeUserGesture()
call.
BUG=670770, 589894
Committed: https://crrev.com/70efdd1328c65ad6042b296659a8e3f733a4e2ca
Cr-Commit-Position: refs/heads/master@{#436721}
Patch Set 1 #
Total comments: 1
Patch Set 2 : Rebase #
Messages
Total messages: 30 (19 generated)
The CQ bit was checked by alexmos@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Remove user gesture consumption from RenderFrameProxy::navigate. RenderFrameProxy::navigate should never result in opening a new tab (see RenderFrameProxyHost::OnOpenURL, which DCHECKs that the disposition is for a current tab). Yet, it currently unconditionally consumes the user gesture. This leads to problems if a frame tries to later consume the gesture, e.g., by opening a popup after navigating a remote frame. This CL removes that incorrect consumeUserGesture call. BUG=670770 ========== to ========== Remove user gesture consumption from RenderFrameProxy::navigate. RenderFrameProxy::navigate should never result in opening a new tab (see RenderFrameProxyHost::OnOpenURL, which DCHECKs that the disposition is for a current tab). Yet, it currently unconditionally consumes the user gesture. This leads to problems if a frame tries to later consume the gesture, e.g., by opening a popup, after navigating a remote frame. This CL removes that problematic consumeUserGesture() call. BUG=670770, 589894 ==========
Description was changed from ========== Remove user gesture consumption from RenderFrameProxy::navigate. RenderFrameProxy::navigate should never result in opening a new tab (see RenderFrameProxyHost::OnOpenURL, which DCHECKs that the disposition is for a current tab). Yet, it currently unconditionally consumes the user gesture. This leads to problems if a frame tries to later consume the gesture, e.g., by opening a popup, after navigating a remote frame. This CL removes that problematic consumeUserGesture() call. BUG=670770, 589894 ========== to ========== Don't consume user gesture in RenderFrameProxy::navigate. RenderFrameProxy::navigate should never result in opening a new tab (see RenderFrameProxyHost::OnOpenURL, which DCHECKs that the disposition is for a current tab). Yet, it currently unconditionally consumes the user gesture. This leads to problems if a frame tries to later consume the gesture, e.g., by opening a popup, after navigating a remote frame. This CL removes that problematic consumeUserGesture() call. BUG=670770, 589894 ==========
Description was changed from ========== Don't consume user gesture in RenderFrameProxy::navigate. RenderFrameProxy::navigate should never result in opening a new tab (see RenderFrameProxyHost::OnOpenURL, which DCHECKs that the disposition is for a current tab). Yet, it currently unconditionally consumes the user gesture. This leads to problems if a frame tries to later consume the gesture, e.g., by opening a popup, after navigating a remote frame. This CL removes that problematic consumeUserGesture() call. BUG=670770, 589894 ========== to ========== Don't consume user gesture in RenderFrameProxy::navigate. RenderFrameProxy::navigate should never result in opening a new tab (see RenderFrameProxyHost::OnOpenURL, which DCHECKs that the disposition is for a current tab). Yet, it currently unconditionally consumes the user gesture. This leads to problems if a frame tries to later consume the gesture, e.g., by opening a popup, after navigating a remote frame. This CL removes that problematic consumeUserGesture() call. BUG=670770, 589894 ==========
alexmos@chromium.org changed reviewers: + japhet@chromium.org, lukasza@chromium.org
Nate, can you please take a look at whether this makes sense? The consumeUserGesture in RFP::navigate traces back to your https://codereview.chromium.org/574403002. I think we don't need it, as navigating a remote frame should never actually open a new window. (New popups should always start as LocalFrames.) Lukasz, I know you've looked at this area recently with middle-clicks, etc., so can you also verify that you can't create popups via RFP::navigate? I'm assuming that based on this comment in RFPH::OnOpenURL: // Since this navigation targeted a specific RenderFrameProxy, it should stay // in the current tab. DCHECK_EQ(WindowOpenDisposition::CURRENT_TAB, params.disposition); https://codereview.chromium.org/2553783003/diff/1/content/renderer/render_fra... File content/renderer/render_frame_proxy.cc (right): https://codereview.chromium.org/2553783003/diff/1/content/renderer/render_fra... content/renderer/render_frame_proxy.cc:463: params.user_gesture = request.hasUserGesture(); We already set this on the request in RemoteFrame::navigate(request), so I'm just reusing that here instead of re-computing. (We end up never using this bit on the browser side currently, fwiw.) I noticed there's some other potential user gesture cleanup in RemoteFrame::navigate (e.g., looks like userGestureStatus is never actually used), but I'll try that out in another CL.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
On 2016/12/06 01:58:05, alexmos wrote: > Nate, can you please take a look at whether this makes sense? > > The consumeUserGesture in RFP::navigate traces back to your > https://codereview.chromium.org/574403002. I think we don't need it, as > navigating a remote frame should never actually open a new window. (New popups > should always start as LocalFrames.) > > Lukasz, I know you've looked at this area recently with middle-clicks, etc., so > can you also verify that you can't create popups via RFP::navigate? I'm > assuming that based on this comment in RFPH::OnOpenURL: > > // Since this navigation targeted a specific RenderFrameProxy, it should stay > // in the current tab. > DCHECK_EQ(WindowOpenDisposition::CURRENT_TAB, params.disposition); > > https://codereview.chromium.org/2553783003/diff/1/content/renderer/render_fra... > File content/renderer/render_frame_proxy.cc (right): > > https://codereview.chromium.org/2553783003/diff/1/content/renderer/render_fra... > content/renderer/render_frame_proxy.cc:463: params.user_gesture = > request.hasUserGesture(); > We already set this on the request in RemoteFrame::navigate(request), so I'm > just reusing that here instead of re-computing. (We end up never using this bit > on the browser side currently, fwiw.) I noticed there's some other potential > user gesture cleanup in RemoteFrame::navigate (e.g., looks like > userGestureStatus is never actually used), but I'll try that out in another CL.
On 2016/12/06 01:58:05, alexmos wrote: > Nate, can you please take a look at whether this makes sense? > > The consumeUserGesture in RFP::navigate traces back to your > https://codereview.chromium.org/574403002. I think we don't need it, as > navigating a remote frame should never actually open a new window. (New popups > should always start as LocalFrames.) > > Lukasz, I know you've looked at this area recently with middle-clicks, etc., so > can you also verify that you can't create popups via RFP::navigate? I'm > assuming that based on this comment in RFPH::OnOpenURL: > > // Since this navigation targeted a specific RenderFrameProxy, it should stay > // in the current tab. > DCHECK_EQ(WindowOpenDisposition::CURRENT_TAB, params.disposition); > Yes - this change seems reasonable: - We consume the user gesture in RenderFrameImpl::OpenURL only in cases where window disposition causes a new window to open. - We always use "current tab" window disposition in RenderFrameProxy::navigate PS. Sorry for sending an empty reply a few minutes ago (caused by fat fingers + bouncy bus ride).
LGTM, but I'm not an OWNER out here.
alexmos@chromium.org changed reviewers: + creis@chromium.org
Charlie, can you please review for OWNERS?
Thanks! LGTM.
The CQ bit was checked by alexmos@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Failed to apply patch for chrome/browser/chrome_site_per_process_browsertest.cc: While running git apply --index -p1; error: patch failed: chrome/browser/chrome_site_per_process_browsertest.cc:343 error: chrome/browser/chrome_site_per_process_browsertest.cc: patch does not apply Patch: chrome/browser/chrome_site_per_process_browsertest.cc Index: chrome/browser/chrome_site_per_process_browsertest.cc diff --git a/chrome/browser/chrome_site_per_process_browsertest.cc b/chrome/browser/chrome_site_per_process_browsertest.cc index ccadca9650b8c4e0fd1fd595be0ee43ca0cffeee..06f6a174654f8c00b8b54592882af6167541d615 100644 --- a/chrome/browser/chrome_site_per_process_browsertest.cc +++ b/chrome/browser/chrome_site_per_process_browsertest.cc @@ -343,3 +343,39 @@ IN_PROC_BROWSER_TEST_F(ChromeSitePerProcessPDFTest, // Wait until the guest for PDF is created. test_guest_view_manager()->WaitForSingleGuestCreated(); } + +// Verify that a popup can be opened after navigating a remote frame. This has +// to be a chrome/ test to ensure that the popup blocker doesn't block the +// popup. See https://crbug.com/670770. +IN_PROC_BROWSER_TEST_F(ChromeSitePerProcessTest, + NavigateRemoteFrameAndOpenPopup) { + // Start on a page with an <iframe>. + GURL main_url(embedded_test_server()->GetURL("a.com", "/iframe.html")); + ui_test_utils::NavigateToURL(browser(), main_url); + + // Navigate the iframe cross-site. + content::WebContents* active_web_contents = + browser()->tab_strip_model()->GetActiveWebContents(); + GURL frame_url(embedded_test_server()->GetURL("b.com", "/title1.html")); + EXPECT_TRUE(NavigateIframeToURL(active_web_contents, "test", frame_url)); + + // Run a script in the parent frame to (1) navigate iframe to another URL, + // and (2) open a popup. Note that ExecuteScript will run this with a user + // gesture, so both steps should succeed. + frame_url = embedded_test_server()->GetURL("c.com", "/title1.html"); + content::WindowedNotificationObserver popup_observer( + chrome::NOTIFICATION_TAB_ADDED, + content::NotificationService::AllSources()); + bool popup_handle_is_valid = false; + EXPECT_TRUE(ExecuteScriptAndExtractBool( + active_web_contents, + "document.querySelector('iframe').src = '" + frame_url.spec() + "';\n" + "var w = window.open('about:blank');\n" + "window.domAutomationController.send(!!w);\n", + &popup_handle_is_valid)); + popup_observer.Wait(); + + // The popup shouldn't be blocked. + EXPECT_TRUE(popup_handle_is_valid); + ASSERT_EQ(2, browser()->tab_strip_model()->count()); +}
The CQ bit was checked by alexmos@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by alexmos@chromium.org
The CQ bit was checked by alexmos@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from creis@chromium.org, japhet@chromium.org Link to the patchset: https://codereview.chromium.org/2553783003/#ps20001 (title: "Rebase")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 20001, "attempt_start_ts": 1481055071298150,
"parent_rev": "38c5c63375f2448493445829ecedfd79cc50e644", "commit_rev":
"03494f8d169b6c08acaf8e9c178c4ffd7b011ecb"}
Message was sent while issue was closed.
Description was changed from ========== Don't consume user gesture in RenderFrameProxy::navigate. RenderFrameProxy::navigate should never result in opening a new tab (see RenderFrameProxyHost::OnOpenURL, which DCHECKs that the disposition is for a current tab). Yet, it currently unconditionally consumes the user gesture. This leads to problems if a frame tries to later consume the gesture, e.g., by opening a popup, after navigating a remote frame. This CL removes that problematic consumeUserGesture() call. BUG=670770, 589894 ========== to ========== Don't consume user gesture in RenderFrameProxy::navigate. RenderFrameProxy::navigate should never result in opening a new tab (see RenderFrameProxyHost::OnOpenURL, which DCHECKs that the disposition is for a current tab). Yet, it currently unconditionally consumes the user gesture. This leads to problems if a frame tries to later consume the gesture, e.g., by opening a popup, after navigating a remote frame. This CL removes that problematic consumeUserGesture() call. BUG=670770, 589894 ==========
Message was sent while issue was closed.
Committed patchset #2 (id:20001)
Message was sent while issue was closed.
Description was changed from ========== Don't consume user gesture in RenderFrameProxy::navigate. RenderFrameProxy::navigate should never result in opening a new tab (see RenderFrameProxyHost::OnOpenURL, which DCHECKs that the disposition is for a current tab). Yet, it currently unconditionally consumes the user gesture. This leads to problems if a frame tries to later consume the gesture, e.g., by opening a popup, after navigating a remote frame. This CL removes that problematic consumeUserGesture() call. BUG=670770, 589894 ========== to ========== Don't consume user gesture in RenderFrameProxy::navigate. RenderFrameProxy::navigate should never result in opening a new tab (see RenderFrameProxyHost::OnOpenURL, which DCHECKs that the disposition is for a current tab). Yet, it currently unconditionally consumes the user gesture. This leads to problems if a frame tries to later consume the gesture, e.g., by opening a popup, after navigating a remote frame. This CL removes that problematic consumeUserGesture() call. BUG=670770, 589894 Committed: https://crrev.com/70efdd1328c65ad6042b296659a8e3f733a4e2ca Cr-Commit-Position: refs/heads/master@{#436721} ==========
Message was sent while issue was closed.
Patchset 2 (id:??) landed as https://crrev.com/70efdd1328c65ad6042b296659a8e3f733a4e2ca Cr-Commit-Position: refs/heads/master@{#436721} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
