Allow Signin page to open other chrome:// URLs if login content in <webview>

extensions/browser/guest_view/web_view/web_view_guest.cc

Index: extensions/browser/guest_view/web_view/web_view_guest.cc
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 fce1b6d0dd7301210ed877a2f3b7f2794649e4fe..5b39567964dd76bfd6113468e4ebf995707ef603 100644
--- a/extensions/browser/guest_view/web_view/web_view_guest.cc
+++ b/extensions/browser/guest_view/web_view/web_view_guest.cc
@@ -1118,6 +1118,21 @@ void WebViewGuest::AddNewContents(content::WebContents* source,
 content::WebContents* WebViewGuest::OpenURLFromTab(
     content::WebContents* source,
     const content::OpenURLParams& params) {
+  // There are two use cases to consider from a security perspective:
+  // 1.) Renderer-initiated nav to chrome:// must always be blocked even if
+  //     the <webview> is in WebUI. This is handled by
+  //     WebViewGuest::NavigateGuest.

[Charlie Reis, 2015/02/18 22:32:06]

nit: It's not obvious how we get to NavigateGuest.  Can you mention the line(s)
below that goes there?  

(Is it LoadURLWithParams?  CreateNewGuestWebViewWindow?  Both?  I don't see it
in either, so I'm concerned that we're not actually covered.)

+  // 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(
+        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.