Bug 1575092 - don't spawn Shared/Service Workers in "web COOP+COEP" processes r=asuth
authorPerry Jiang <perry@mozilla.com>
Tue, 12 Nov 2019 15:46:05 +0000
changeset 501981 8dc03b744500555e87b7506bd317a6c70438603c
parent 501980 e28e46ca4a17fc887d2f206b13bca33d205112d7
child 501982 29ad799700cde08c67fae646439e1bbdb6a1ede2
push id36803
push userrmaries@mozilla.com
push dateThu, 14 Nov 2019 21:46:28 +0000
treeherdermozilla-central@0fb79a3edf1b [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersasuth
bugs1575092
milestone72.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1575092 - don't spawn Shared/Service Workers in "web COOP+COEP" processes r=asuth Preventing RemoteWorkerService from existing in "web COOP+COEP" content processes prevents Shared/ServiceWorkers from being spawned in them because there won't be an associated RemoteWorkerServiceParent that registers with the parent process RemoteWorkerManager. Differential Revision: https://phabricator.services.mozilla.com/D50815
dom/ipc/ContentChild.cpp
dom/workers/remoteworkers/RemoteWorkerManager.cpp
--- a/dom/ipc/ContentChild.cpp
+++ b/dom/ipc/ContentChild.cpp
@@ -1345,17 +1345,27 @@ void ContentChild::InitXPCOM(
     MOZ_ASSERT_UNREACHABLE("PBackground init can't fail at this point");
     return;
   }
 
   LSObject::Initialize();
 
   ClientManager::Startup();
 
-  RemoteWorkerService::Initialize();
+  // Respecting COOP and COEP requires processing headers in the parent process
+  // in order to choose an appropriate content process, but the workers'
+  // ScriptLoader processes headers in content processes. An intermediary step
+  // that provides security guarantees is to simply never allow SharedWorkers
+  // and ServiceWorkers to exist in a COOP+COEP process. The ultimate goal
+  // is to allow these worker types to be put in such processes based on their
+  // script response headers.
+  // https://bugzilla.mozilla.org/show_bug.cgi?id=1595206
+  if (!IsWebCoopCoepRemoteType(GetRemoteType())) {
+    RemoteWorkerService::Initialize();
+  }
 
   nsCOMPtr<nsIConsoleService> svc(do_GetService(NS_CONSOLESERVICE_CONTRACTID));
   if (!svc) {
     NS_WARNING("Couldn't acquire console service");
     return;
   }
 
   mConsoleListener = new ConsoleListener(this);
--- a/dom/workers/remoteworkers/RemoteWorkerManager.cpp
+++ b/dom/workers/remoteworkers/RemoteWorkerManager.cpp
@@ -234,17 +234,22 @@ RemoteWorkerManager::SelectTargetActorFo
     MOZ_ASSERT(bgParent);
 
     RefPtr<ContentParent> contentParent =
         BackgroundParent::GetContentParent(bgParent);
 
     auto scopeExit = MakeScopeExit(
         [&] { contentParents.AppendElement(std::move(contentParent)); });
 
-    if (IsWebRemoteType(contentParent->GetRemoteType())) {
+    const nsAString& remoteType = contentParent->GetRemoteType();
+    MOZ_DIAGNOSTIC_ASSERT(
+        !IsWebCoopCoepRemoteType(remoteType),
+        "COOP+COEP processes don't support remote workers right now");
+
+    if (IsWebRemoteType(remoteType)) {
       auto lock = contentParent->mRemoteWorkerActorData.Lock();
 
       if (lock->mCount || !lock->mShutdownStarted) {
         ++lock->mCount;
 
         // This won't cause any race conditions because the content process
         // should wait for the permissions to be received before executing the
         // Service Worker.