Pages controlled by ServiceWorkers should not participate in AppCaching

content/browser/storage_partition_impl_map.cc

Index: content/browser/storage_partition_impl_map.cc
diff --git a/content/browser/storage_partition_impl_map.cc b/content/browser/storage_partition_impl_map.cc
index 9042d173e3bd81a2a6ef79e785fbc6ac1f1d4ab5..6ff893e82017b8dba9158a977e978d07305907e3 100644
--- a/content/browser/storage_partition_impl_map.cc
+++ b/content/browser/storage_partition_impl_map.cc
@@ -14,6 +14,7 @@
 #include "base/strings/string_util.h"
 #include "base/strings/stringprintf.h"
 #include "base/threading/sequenced_worker_pool.h"
+#include "content/browser/appcache/appcache_interceptor.h"
 #include "content/browser/appcache/chrome_appcache_service.h"
 #include "content/browser/fileapi/browser_file_system_helper.h"
 #include "content/browser/fileapi/chrome_blob_storage_context.h"
@@ -436,6 +437,8 @@ StoragePartitionImpl* StoragePartitionImplMap::Get(
   URLRequestInterceptorScopedVector request_interceptors;
   request_interceptors.push_back(
       ServiceWorkerRequestHandler::CreateInterceptor().release());
+  request_interceptors.push_back(
+      AppCacheInterceptor::CreateStartInterceptor().release());

[michaeln, 2014/10/10 21:55:40]

here's how we get the ordering we want

[falken, 2014/10/14 01:24:49]

It took me a while to see how this works. Before this CL, AppCache was called
before SW, so just adding the interceptor here (and not removing something
elsewhere) wouldn't seem to fix it. Now I see... the original
AppCacheInterceptor::MaybeIntercept is still called first but now does nothing
and the StartInterceptor is the one that really chooses whether AppCache kicks
in?

[michaeln, 2014/10/14 01:52:42]

Thats right.

 
   // These calls must happen after StoragePartitionImpl::Create().
   if (partition_domain.empty()) {