Add an ability to call WebKit's WebFrame::loadData via NavigationController.

content/browser/renderer_host/render_view_host_impl.cc

 // Copyright (c) 2012 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 "content/browser/renderer_host/render_view_host_impl.h"
 
 #include <set>
 #include <string>
 #include <utility>
 #include <vector>
@@ skipping 285 matching lines @@
 
 void RenderViewHostImpl::SyncRendererPrefs() {
   Send(new ViewMsg_SetRendererPrefs(GetRoutingID(),
                                     delegate_->GetRendererPrefs(
                                         GetProcess()->GetBrowserContext())));
 }
 
 void RenderViewHostImpl::Navigate(const ViewMsg_Navigate_Params& params) {
   ChildProcessSecurityPolicyImpl::GetInstance()->GrantRequestURL(
       GetProcess()->GetID(), params.url);
+  if (!params.base_url_for_data_url.is_empty() &&
+      params.url.SchemeIs(chrome::kDataScheme)) {
+    // If 'data:' scheme is used, and we have a base url, grant access to
+    // local files if baseUrl specifies a scheme other than 'http', 'https',
+    // 'ftp', 'about' or 'javascript'.

[Charlie Reis, 2012/07/03 17:54:37]

This doesn't make sense to me.  Why would we grant access to file URLs if it
doesn't match this list?  What if additional schemes are added in the future?

[mnaganov (inactive), 2012/07/04 15:25:57]

This is according to http://goo.gl/X8HOs. As the main URL uses the 'data:'
scheme, client security policy forbids it from loading 'file:' URLs. I think the
main use case for this is allowing to access 'file:' URLs when the base URL is
also 'file:', although the documentation doesn't state this directly.

[Charlie Reis, 2012/07/10 20:54:19]

Hmm.  This sounds like it's following the letter of the law if not the spirit. 
Again, Chrome may support more schemes than Android's WebView, so this blacklist
approach may grant file:// privileges more often than the doc writers meant to. 
I'd feel much more comfortable only granting file:// privileges if the base URL
is file://.  If that turns out to be a bug in a corner case, we can revisit it.

[mnaganov (inactive), 2012/07/23 14:02:29]

I agree -- whitelisting allowed schemes is more secure than blacklisting. I
myself was surprised with the wording in the documentation.

+    if (!params.base_url_for_data_url.SchemeIs(chrome::kHttpScheme) &&
+        !params.base_url_for_data_url.SchemeIs(chrome::kHttpsScheme) &&
+        !params.base_url_for_data_url.SchemeIs(chrome::kFtpScheme) &&
+        !params.base_url_for_data_url.SchemeIs(chrome::kAboutScheme) &&
+        !params.base_url_for_data_url.SchemeIs(chrome::kJavaScriptScheme)) {
+      std::string file_url(chrome::kFileScheme);
+      file_url += content::kStandardSchemeSeparator;
+      ChildProcessSecurityPolicyImpl::GetInstance()->GrantRequestURL(
+          GetProcess()->GetID(), GURL(file_url));
+    }
+  }
 
   ViewMsg_Navigate* nav_message = new ViewMsg_Navigate(GetRoutingID(), params);
 
   // Only send the message if we aren't suspended at the start of a cross-site
   // request.
   if (navigations_suspended_) {
     // Shouldn't be possible to have a second navigation while suspended, since
     // navigations will only be suspended during a cross-site request.  If a
     // second navigation occurs, WebContentsImpl will cancel this pending RVH
     // create a new pending RVH.
@@ skipping 1530 matching lines @@
   // can cause navigations to be ignored in OnMsgNavigate.
   is_waiting_for_beforeunload_ack_ = false;
   is_waiting_for_unload_ack_ = false;
 }
 
 void RenderViewHostImpl::ClearPowerSaveBlockers() {
   STLDeleteValues(&power_save_blockers_);
 }
 
 }  // namespace content