diff options
| author | wjmaclean <wjmaclean@chromium.org> | 2015-09-29 15:44:17 -0700 |
|---|---|---|
| committer | Commit bot <commit-bot@chromium.org> | 2015-09-29 22:45:35 +0000 |
| commit | cfe0de44de3d2916c2d7254027cb70e0c7c14e0d (patch) | |
| tree | 60d201290502c5fa258a5a938f6ad70b90fbfcff /extensions/browser | |
| parent | 661a7b9827101da6f1d7a64fe1b71572698d1b69 (diff) | |
| download | chromium_src-cfe0de44de3d2916c2d7254027cb70e0c7c14e0d.zip chromium_src-cfe0de44de3d2916c2d7254027cb70e0c7c14e0d.tar.gz chromium_src-cfe0de44de3d2916c2d7254027cb70e0c7c14e0d.tar.bz2 | |
PDFs viewed inside a <webview> should navigate the same as PDFs in tabs.
This CL is (sort-of) a reland of
(1) https://codereview.chromium.org/1234403005/
as well as a revert of
(2) https://codereview.chromium.org/1275173004
CL (2) broke the CL (1), in that chrome.tabs.update will always
update the active tab in the browser window. If a user left-clicks on
a link in the PDF viewer, the expectation is that the PDF contents will
be replaced by the contents at the link, but that cannot happen
if the PDF is displayed in an app and chrome.tabs.update is used.
Also, https://codereview.chromium.org/1275173004 suggests that the
advantage of chrome.tabs.update is to navigate from one file:// url
to another, but based on other discussions,
https://code.google.com/p/chromium/issues/detail?id=528505
this may not be appropriate.
Finally, CL (1) broke context-menu navigations for links within webviews,
namely "open in new tab", "open in new window" and "open in incognito
window". This CL restricts itself to CURRENT_TAB navigations in order to
fix that.
BUG=532621
Review URL: https://codereview.chromium.org/1350073002
Cr-Commit-Position: refs/heads/master@{#351423}
Diffstat (limited to 'extensions/browser')
| -rw-r--r-- | extensions/browser/guest_view/web_view/web_view_guest.cc | 25 |
1 files changed, 14 insertions, 11 deletions
diff --git a/extensions/browser/guest_view/web_view/web_view_guest.cc b/extensions/browser/guest_view/web_view/web_view_guest.cc index e96b30e..f4d1cc4 100644 --- a/extensions/browser/guest_view/web_view/web_view_guest.cc +++ b/extensions/browser/guest_view/web_view/web_view_guest.cc @@ -1235,17 +1235,20 @@ void WebViewGuest::AddNewContents(WebContents* source, WebContents* WebViewGuest::OpenURLFromTab( WebContents* source, const content::OpenURLParams& params) { - // There are two use cases to consider from a security perspective: - // 1.) Renderer-initiated navigation to chrome:// must always be blocked even - // if the <webview> is in WebUI. This is handled by - // WebViewGuest::LoadURLWithParams. WebViewGuest::NavigateGuest will also - // call LoadURLWithParams. CreateNewGuestWebViewWindow creates a new - // WebViewGuest which will call NavigateGuest in DidInitialize. - // 2.) The Language Settings context menu item should always work, both in - // Chrome Apps and WebUI. This is a browser initiated request and so - // we pass it along to the embedder's WebContentsDelegate to get the - // browser to perform the action for the <webview>. - if (!params.is_renderer_initiated) { + // Most navigations should be handled by WebViewGuest::LoadURLWithParams, + // which takes care of blocking chrome:// URLs and other web-unsafe schemes. + // (NavigateGuest and CreateNewGuestWebViewWindow also go through + // LoadURLWithParams.) + // + // We make an exception here for context menu items, since the Language + // Settings item uses a browser-initiated navigation to a chrome:// URL. + // These can be passed to the embedder's WebContentsDelegate so that the + // browser performs the action for the <webview>. Navigations to a new + // tab, etc., are also handled by the WebContentsDelegate. + if (!params.is_renderer_initiated && + (!content::ChildProcessSecurityPolicy::GetInstance()->IsWebSafeScheme( + params.url.scheme()) || + params.disposition != CURRENT_TAB)) { if (!owner_web_contents()->GetDelegate()) return nullptr; return owner_web_contents()->GetDelegate()->OpenURLFromTab( |