Change how the quota system computes the total poolsize for temporary storage

content/public/browser/content_browser_client.cc

Index: content/public/browser/content_browser_client.cc
diff --git a/content/public/browser/content_browser_client.cc b/content/public/browser/content_browser_client.cc
index e78e78a52091046836870a95495b54b0e204a8f9..81e86b2654ff999b2e20fc8dd5792698e24c8fae 100644
--- a/content/public/browser/content_browser_client.cc
+++ b/content/public/browser/content_browser_client.cc
@@ -233,6 +233,21 @@ ContentBrowserClient::GetTemporaryStorageEvictionPolicy(
   return std::unique_ptr<storage::QuotaEvictionPolicy>();
 }
 
+namespace {
+void DefaultTemporaryStorageConfigurationFunction(
+    const base::FilePath& profile_path, bool is_incognito,
+    storage::TemporaryStorageConfigurationCallback callback) {
+  // By default, no quota is provided, embedders must override.
+  callback.Run(storage::TemporaryStorageConfiguration());
+}
+}  // namespace
+
+storage::GetTemporaryStorageConfigurationFunc
+ContentBrowserClient::GetTemporaryStorageConfigurationFunction(

[kinuko, 2016/07/27 14:23:25]

I felt it might be slightly awkward to return a callback function from content
client... I imagined ContentClient might be able to simply expose a virtual
method like ContentBrowserClient::GetTemporaryStorageConfiguration() and
QuotaManager can bind it to get a closure if necessary (and run it on the UI
thread).  At least it'd be easier for embedders to understand what it's supposed
to do, but probably there's a reason you didn't take the approach?

[michaeln, 2016/07/27 19:57:47]

That's another option, a virtual method that returns the config via a
TemporaryStorageConfigurationCallback. I think I prefer that too.

virtual void ContentBrowserClient::GetTemporaryStorageConfig(
    BrowserContext* browser_context,
    const storage::TemporaryStorageConfigurationCallback& callback);

The reason i didn't do it that way is that the QuotaManager can't depend on the
content lib defined interface, so the GetTemporaryStorageConfigurationFunc is
needed in the storage lib in any case. By having the chrome layer provide the
getterfunc, grepping for GetTemporaryStorageConfigurationFunc might let folks
find the actual code up in chrome that fills out the config more quickly. But
I'm not sure that's such a good reason.

The reason for invoking the callback on the main thread is due to the thread
affinity of the BrowserContext and ContentBrowserClient, those are main thread
only. Whatever technique is used to expose the function/method, the logic is
related to content settings and other properties of the BrowserContext (and
possibly the StoragePartition at some point).

+    BrowserContext* context) {
+  return base::Bind(&DefaultTemporaryStorageConfigurationFunction);
+}
+
 void ContentBrowserClient::SelectClientCertificate(
     WebContents* web_contents,
     net::SSLCertRequestInfo* cert_request_info,