Revert of Don't refer browser-initiated navigations to web-safe URLs to delegate. (patchset #2 id:20001 of https://codereview.chromium.org/1234403005/ )

Reason for revert:
Since this CL was landed something has changed that causes clinking on links in the PDF viewer (embedded inside another WebView, e.g. the Chrome app "Browser Sample") to open in the wrong window, or in the case of "Open in a new tab", not be opened at all.

Reverting this CL fixes
https://code.google.com/p/chromium/issues/detail?id=529187 and
https://code.google.com/p/chromium/issues/detail?id=521573

A new bug has been filed to capture the error where the links are not opened in the correct target window:

https://code.google.com/p/chromium/issues/detail?id=532621

Original issue's description:
> Don't refer browser-initiated navigations to web-safe URLs to delegate.
>
> In a previous CL (https://codereview.chromium.org/890183002) it was
> decided to refer browser-initiated navigations to the owner WebContents'
> delegate, on the assumption that the navigation was to a non-web-safe
> url (e.g. a "chrome"-scheme url). However, this change can block
> guest navigations to web-safe URLs just because they originated, for
> example, from an extension.
>
> This CL ensures that navigations to web-safe URLs are not referred to
> the delegate in order to allow them to succeed.
>
> BUG=488053
>
> Committed: https://crrev.com/a03c23d32d176daf1e95cfffbfa333316e1eb1a6
> Cr-Commit-Position: refs/heads/master@{#339204}

TBR=creis@chromium.org,lazyboy@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=488053

Review URL: https://codereview.chromium.org/1350893002

Cr-Commit-Position: refs/heads/master@{#349208}

1 files changed, 11 insertions, 12 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 3c3c0e5..e96b30e 100644
--- a/extensions/browser/guest_view/web_view/web_view_guest.cc
+++ b/extensions/browser/guest_view/web_view/web_view_guest.cc
@@ -1235,18 +1235,17 @@ void WebViewGuest::AddNewContents(WebContents* source,
 WebContents* WebViewGuest::OpenURLFromTab(
     WebContents* source,
     const content::OpenURLParams& params) {
-  // 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>.
-  if (!params.is_renderer_initiated &&
-      !content::ChildProcessSecurityPolicy::GetInstance()->IsWebSafeScheme(
-          params.url.scheme())) {
+  // 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) {
     if (!owner_web_contents()->GetDelegate())
       return nullptr;
     return owner_web_contents()->GetDelegate()->OpenURLFromTab(