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

content/browser/renderer_host/render_view_host_impl.cc

Index: content/browser/renderer_host/render_view_host_impl.cc
diff --git a/content/browser/renderer_host/render_view_host_impl.cc b/content/browser/renderer_host/render_view_host_impl.cc
index f2910cedff5063a1c9d90746329e716726840547..2c2a1b68ca66e1b83049a23a7bc8fbce8cf7acdd 100644
--- a/content/browser/renderer_host/render_view_host_impl.cc
+++ b/content/browser/renderer_host/render_view_host_impl.cc
@@ -303,6 +303,22 @@ void RenderViewHostImpl::SyncRendererPrefs() {
 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);