Split GetPermissionStatus into GetPermissionStatusForFrame/Worker

content/browser/background_sync/background_sync_manager.cc

 // Copyright 2015 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/browser/background_sync/background_sync_manager.h"
 
 #include <utility>
 
 #include "base/barrier_closure.h"
 #include "base/bind.h"
@@ skipping 78 matching lines @@
       GetBrowserContextOnUIThread(std::move(service_worker_context));
   if (!browser_context)
     return blink::mojom::PermissionStatus::DENIED;
 
   PermissionManager* permission_manager =
       browser_context->GetPermissionManager();
   if (!permission_manager)
     return blink::mojom::PermissionStatus::DENIED;
 
   // The requesting origin always matches the embedding origin.
-  return permission_manager->GetPermissionStatus(
-      PermissionType::BACKGROUND_SYNC, origin, origin);
+  return permission_manager->GetPermissionStatusForWorker(

[johnme, 2017/06/12 10:18:20]

Is this correct? It seems that this codepath applies both to bgsync
registrations from frames and from service workers, so for example it'll
incorrectly return DENIED for requests from frames.

In general there are quite a few codepaths like this that can be reached both
via requests from frames and via requests from workers. Such codepaths are
merged to avoid code duplication. It's going to be awkward if they need to start
plumbing different argument types depending on the source of the request,
through all the layers. If that's really necessary, it might be useful to have a
PermissionRequestSource type in both content and Blink that can be initialised
with either a frame or worker.

Currently Feature Policy doesn't include
(https://wicg.github.io/feature-policy/#defined-features) any features that seem
relevant to workers/Service Workers (e.g. notifications). Is that deliberate, to
avoid the loophole where a restricted frame spawns a worker/SW that is
unrestricted? Or will Feature Policy eventually allow preventing
installing/spawning workers/SWs? If Feature Policy isn't planned to cover APIs
available in workers/SWs, perhaps we can just have a
GetPermissionStatusForAPIExposedInWorkers method that can be used in such merged
codepaths.

+      PermissionType::BACKGROUND_SYNC, origin);
 }
 
 void NotifyBackgroundSyncRegisteredOnUIThread(
     scoped_refptr<ServiceWorkerContextWrapper> sw_context_wrapper,
     const GURL& origin) {
   DCHECK_CURRENTLY_ON(BrowserThread::UI);
 
   BackgroundSyncController* background_sync_controller =
       GetBackgroundSyncControllerOnUIThread(std::move(sw_context_wrapper));
 
@@ skipping 1053 matching lines @@
   parameters_->max_sync_attempts = max_attempts;
   base::ThreadTaskRunnerHandle::Get()->PostTask(FROM_HERE, callback);
 }
 
 base::Closure BackgroundSyncManager::MakeEmptyCompletion() {
   DCHECK_CURRENTLY_ON(BrowserThread::IO);
   return op_scheduler_.WrapCallbackToRunNext(base::Bind(&base::DoNothing));
 }
 
 }  // namespace content