Bugzilla

== Original Context

The nsPermissionManager service in each process only knows about the permissions it has been told about.  These are sent down from the parent process to the content process when appropriate.  The permission manager knows when it doesn't have permissions that it's being asked about, allowing it to assert.

Bug 1337056 changed how the permission manager worked (sync => async).  Bug 1353179 fixed a problem in the assertion check about permissions being available, which helped detect the problem that led to bug 1355608.  In bug 1355608 we addressed the problem where a SW might intercept a navigation request for an origin that had not yet been loaded in that content process, and so there were no permissions available, tripping the new assertion.  The problem was addressed by both:
1. Propagating permissions for a registered origin to all ContentProcesses when propagating registrations.
2. Making the fetch event dispatching stall, waiting for the permissions to be available.

So in bug comment 21, the concern was that we might end up spawning a ServiceWorker in a content process where permissions were not available because the origin had not previously been opened in the given content process.  Because of how the bug ended up being fixed, this would indefinitely stall the processing of the fetch event rather than tripping the permission check assertion, which is bad in its own way.

An extra edge case is that since bug 1355608 ServiceWorker registrations are eagerly transmitted at ContentParent::InitInternal time.

== Current Test Proposal

To satisfy the original test goal and knowing the implementation we want:
- Have 2 processes.
- In process A register a SW for an origin.  This should propagate permissions to process B.
- Terminate process A.
- Open a controlled page in process B and verify that it is intercepted and responds in a timely fashion.
- Terminate process B.
- Open a controlled page in new process C.  (Process C only need be created after the SW registration propagation has occurred, so it's okay if this was a pre-allocated process as long as we can guarantee it was after registration.)

Note that there's a somewhat related issue of whether updated permissions are propagated, but I believe the fresh process usage covers that.  If we wanted to delve into that, the existing test https://searchfox.org/mozilla-central/source/dom/serviceworkers/test/browser_storage_permission.js is probably a good place to start.

== Related Tests We Want

For the e10s refactor, we also want a browser test that opens the same controlled scope for origin 1 in process A and process B and verifies that the resulting tabs both see the same ServiceWorker with the same global.  This is somewhat of a separate issue, except that if we allow the SW to be spawned in a third process that is not where either of the tabs are being loaded, then that is a nice test of the permission sending or permission-verification-in-the-parent logic.  It's not clear we would ever want to intentionally support that behavior, but that is already how push notifications will be handled, and it's conceivable that in extreme cases the process initiating the navigation fetch to be intercepted dies before the ServiceWorker gets to process selection.

### Original Context

The nsPermissionManager service in each process only knows about the permissions it has been told about.  These are sent down from the parent process to the content process when appropriate.  The permission manager knows when it doesn't have permissions that it's being asked about, allowing it to assert.

Bug 1337056 changed how the permission manager worked (sync => async).  Bug 1353179 fixed a problem in the assertion check about permissions being available, which helped detect the problem that led to bug 1355608.  In bug 1355608 we addressed the problem where a SW might intercept a navigation request for an origin that had not yet been loaded in that content process, and so there were no permissions available, tripping the new assertion.  The problem was addressed by both:
1. Propagating permissions for a registered origin to all ContentProcesses when propagating registrations.
2. Making the fetch event dispatching stall, waiting for the permissions to be available.

So in bug comment 21, the concern was that we might end up spawning a ServiceWorker in a content process where permissions were not available because the origin had not previously been opened in the given content process.  Because of how the bug ended up being fixed, this would indefinitely stall the processing of the fetch event rather than tripping the permission check assertion, which is bad in its own way.

An extra edge case is that since bug 1355608 ServiceWorker registrations are eagerly transmitted at ContentParent::InitInternal time.

### Current Test Proposal

To satisfy the original test goal and knowing the implementation we want:
- Have 2 processes.
- In process A register a SW for an origin.  This should propagate permissions to process B.
- Terminate process A.
- Open a controlled page in process B and verify that it is intercepted and responds in a timely fashion.
- Terminate process B.
- Open a controlled page in new process C.  (Process C only need be created after the SW registration propagation has occurred, so it's okay if this was a pre-allocated process as long as we can guarantee it was after registration.)

Note that there's a somewhat related issue of whether updated permissions are propagated, but I believe the fresh process usage covers that.  If we wanted to delve into that, the existing test https://searchfox.org/mozilla-central/source/dom/serviceworkers/test/browser_storage_permission.js is probably a good place to start.

### Related Tests We Want

For the e10s refactor, we also want a browser test that opens the same controlled scope for origin 1 in process A and process B and verifies that the resulting tabs both see the same ServiceWorker with the same global.  This is somewhat of a separate issue, except that if we allow the SW to be spawned in a third process that is not where either of the tabs are being loaded, then that is a nice test of the permission sending or permission-verification-in-the-parent logic.  It's not clear we would ever want to intentionally support that behavior, but that is already how push notifications will be handled, and it's conceivable that in extreme cases the process initiating the navigation fetch to be intercepted dies before the ServiceWorker gets to process selection.