Start of foreign fetch implementation.

content/common/service_worker/service_worker_messages.h

Index: content/common/service_worker/service_worker_messages.h
diff --git a/content/common/service_worker/service_worker_messages.h b/content/common/service_worker/service_worker_messages.h
index 8164130334d5801bd363e42aa60a47ed07a0bfcd..104dc32214921dab9d687a0d33cda57a7d11163e 100644
--- a/content/common/service_worker/service_worker_messages.h
+++ b/content/common/service_worker/service_worker_messages.h
@@ -290,6 +290,11 @@ IPC_MESSAGE_ROUTED1(ServiceWorkerHostMsg_SkipWaiting,
 IPC_MESSAGE_ROUTED1(ServiceWorkerHostMsg_ClaimClients,
                     int /* request_id */)
 
+// Informs the browser of new foreign fetch subscopes this worker wants to
+// handle. Should only be sent while an install event is being handled.

[Tom Sepez, 2015/10/16 18:12:39]

What happens if an evil renderer doesn't adhere to this restriction?

[Marijn Kruisselbrink, 2015/10/16 18:29:10]

Currently the browser process DCHECKs this (the same way OnInstallEventFinished
and OnActivateEventFinished DCHECK if they are called when the service worker is
not in the correct state).
In case DCHECKs are enabled the browser just accepts the IPC anyway (and still
checks if the URLs are valid, within the scope of the worker, etc). If the
worker isn't installing though, any urls received will probably not be stored
(since storing generally happens on completion of the install event), so they'll
probably not end up being used. Foreign fetch hings might behave unpredictably,
but renderers won't be able to do anything this way a well behaved
renderer/service worker wouldn't be able to do anyway.

+IPC_MESSAGE_ROUTED1(ServiceWorkerHostMsg_RegisterForeignFetchScopes,
+                    std::vector<GURL> /* sub_scopes */)
+
 //---------------------------------------------------------------------------
 // Messages sent from the browser to the child process.
 //