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

content/public/browser/content_browser_client.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/public/browser/content_browser_client.h"
 
 #include "base/files/file_path.h"
 #include "base/guid.h"
 #include "build/build_config.h"
 #include "content/public/browser/client_certificate_delegate.h"
@@ skipping 215 matching lines @@
 QuotaPermissionContext* ContentBrowserClient::CreateQuotaPermissionContext() {
   return nullptr;
 }
 
 std::unique_ptr<storage::QuotaEvictionPolicy>
 ContentBrowserClient::GetTemporaryStorageEvictionPolicy(
     content::BrowserContext* context) {
   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,
     std::unique_ptr<ClientCertificateDelegate> delegate) {}
 
 net::URLRequestContext* ContentBrowserClient::OverrideRequestContextForURL(
     const GURL& url, ResourceContext* context) {
   return nullptr;
 }
 
@@ skipping 176 matching lines @@
 #if defined(VIDEO_HOLE)
 ExternalVideoSurfaceContainer*
 ContentBrowserClient::OverrideCreateExternalVideoSurfaceContainer(
     WebContents* web_contents) {
   NOTREACHED() << "Hole-punching is not supported. See crbug.com/469348.";
   return nullptr;
 }
 #endif
 
 }  // namespace content