Allow huge data: URIs only via WebView.loadDataWithBaseUrl

content/browser/frame_host/navigation_entry_impl.h

Index: content/browser/frame_host/navigation_entry_impl.h
diff --git a/content/browser/frame_host/navigation_entry_impl.h b/content/browser/frame_host/navigation_entry_impl.h
index 9a13f654b3ac6d494ce3e6fee79e232e1fab5330..87a05ab2b979fb0dbe672ef2f09492f21534fb37 100644
--- a/content/browser/frame_host/navigation_entry_impl.h
+++ b/content/browser/frame_host/navigation_entry_impl.h
@@ -82,6 +82,8 @@ class CONTENT_EXPORT NavigationEntryImpl
   const GURL& GetURL() const override;
   void SetBaseURLForDataURL(const GURL& url) override;
   const GURL& GetBaseURLForDataURL() const override;
+  void SetDataURLAsString(const std::string& url) override;

[Charlie Reis, 2015/12/10 20:43:46]

boliu@ and I spent a lot of time avoiding a new member for the data URL for
https://crbug.com/522567.  I'm sad that we're having to add it (as he predicted
in https://code.google.com/p/chromium/issues/detail?id=525697#c18).

This seems like one more way for NavigationEntries to have inconsistent
information (e.g., this vs GetURL), with subtle bugs if they aren't populated
correctly or checked consistently.

[mnaganov (inactive), 2015/12/11 23:14:23]

I hope I added enough checks to enforce consistency.

We could get rid of the base URL field (put its contents into the main URL
field). But as I'm now making 'DataURLAsString' to be specific to Android, this
will not be possible.

+  const std::string& GetDataURLAsString() const override;
   void SetReferrer(const Referrer& referrer) override;
   const Referrer& GetReferrer() const override;
   void SetVirtualURL(const GURL& url) override;
@@ -420,6 +422,10 @@ class CONTENT_EXPORT NavigationEntryImpl
   // persisted by Android WebView.
   GURL base_url_for_data_url_;
 
+  // Used for passing really big data URLs from browser to renderers. Only used
+  // and persisted by Android WebView.

[Charlie Reis, 2015/12/10 20:43:46]

I'm concerned about the "only Android WebView" comment without having it in an
#ifdef.  The rest of the LoadDataForBaseURL feature leaked to the Chrome Apps
<webview> implementation, so these comments aren't enforceable lead to uses of
this bad API in other parts of Chrome.

If we keep this, can we put it (and the new methods) in an #ifdef?  I don't
think we want to support this hack for LoadDataForBaseURL inside Chrome Apps
<webview>.

[mnaganov (inactive), 2015/12/11 23:14:23]

Now it's enforced by OS_ANDROID defines.

+  std::string data_url_as_string_;

[Charlie Reis, 2015/12/10 20:43:46]

I'd like to consider alternatives to this if we can, as I mention in my overall
CL comment.

[mnaganov (inactive), 2015/12/11 23:14:23]

Considered.

+
   // Whether the entry, while loading, was created for a renderer-initiated
   // navigation.  This dictates whether the URL should be displayed before the
   // navigation commits.  It is cleared in |ResetForCommit| and not persisted.