Don't refer browser-initiated navigations to web-safe URLs to delegate.

extensions/browser/guest_view/web_view/web_view_guest.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "extensions/browser/guest_view/web_view/web_view_guest.h"
 
 #include "base/message_loop/message_loop.h"
 #include "base/strings/stringprintf.h"
 #include "base/strings/utf_string_conversions.h"
 #include "components/browsing_data/storage_partition_http_cache_data_remover.h"
@@ skipping 1205 matching lines @@
   // 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) {
+  // However, browser-initiated navigations (e.g. from extensions) to web-safe
+  // urls should not be referred to the delegate, which may block them.

[Charlie Reis, 2015/07/17 00:05:15]

I feel like this code is getting very difficult to follow or reason about. 
After spending some time refreshing myself on
https://codereview.chromium.org/890183002, I think I've concluded that this
change is safe, since it takes the exception we added (for allowing chrome://
URLs in context menus) and only makes it narrower.  It's pretty hard to conclude
that from reading this whole comment block, so I have a suggested revision
below:

"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>."

[wjmaclean, 2015/07/17 01:29:46]

Yes, that was my conclusion, though I didn't think to describe it in those
terms.
Sure, this seems reasonable ... done.

+  if (!params.is_renderer_initiated &&
+      !content::ChildProcessSecurityPolicy::GetInstance()->IsWebSafeScheme(
+          params.url.scheme())) {
     if (!owner_web_contents()->GetDelegate())
       return nullptr;
     return owner_web_contents()->GetDelegate()->OpenURLFromTab(
         owner_web_contents(), params);
   }
 
   // If the guest wishes to navigate away prior to attachment then we save the
   // navigation to perform upon attachment. Navigation initializes a lot of
   // state that assumes an embedder exists, such as RenderWidgetHostViewGuest.
   // Navigation also resumes resource loading which we don't want to allow
@@ skipping 213 matching lines @@
     scoped_ptr<base::DictionaryValue> args(new base::DictionaryValue());
     DispatchEventToView(
         new GuestViewEvent(webview::kEventExitFullscreen, args.Pass()));
   }
   // Since we changed fullscreen state, sending a Resize message ensures that
   // renderer/ sees the change.
   web_contents()->GetRenderViewHost()->WasResized();
 }
 
 }  // namespace extensions