ServiceWorkerShutdownState encapsulates the shutdown progress for a particular
ServiceWorker. The shutdown process involves a "shutdown message" passing
multiple threads in both parent/content processes; we report a progress update
when it's known that a shutdown message has reached a particular thread. The
idea is that in the event of a shutdown timeout, ServiceWorkerShutdownBlocker
will be able to provide diagnostics for where shutdown processes are stalled.
Differential Revision: https://phabricator.services.mozilla.com/D60791
--HG--
extra : moz-landing-system : lando
ServiceWorkerShutdownState encapsulates the shutdown progress for a particular
ServiceWorker. The shutdown process involves a "shutdown message" passing
multiple threads in both parent/content processes; we report a progress update
when it's known that a shutdown message has reached a particular thread. The
idea is that in the event of a shutdown timeout, ServiceWorkerShutdownBlocker
will be able to provide diagnostics for where shutdown processes are stalled.
Differential Revision: https://phabricator.services.mozilla.com/D60791
--HG--
extra : moz-landing-system : lando
In ServiceWorkerPrivateImpl::SendFetchEvent, a heap-allocated AutoIPCStream can
point to a stack-allocated IPCStream (part of an IPCInternalRequest). If this
IPCStream is destroyed before the AutoIPCStream, the AutoIPCStream will have a
dangling pointer (and this is the case if SendFetchEvent is called when the
Service Worker's state is "activating" rather than "activated").
This patch moves around the logic to handle the AutoIPCStream's lifetime to
ensure it its lifetime is within its IPCStream's lifetime. The larger issue
might be that AutoIPCStream doesn't have inherent lifetime guarantees (it'll
definitely outlive its IPCStream if it points to its embedded one, but it
doesn't own any external IPCStreams it might point to).
Differential Revision: https://phabricator.services.mozilla.com/D48935
--HG--
extra : moz-landing-system : lando
Previously, Service Workers could spawn in a process that isn't subscribed
to permission updates, which could happen if that process hadn't loaded any
same-origin documents. To address this, parent-process logic for spawning
Service Workers would snapshot the permissions state to be sent to a content
process.
Unfortunately, this approach could lead to outdated, unsynchronized permissions.
Note that nsIPermissionManager::SetPermissionsWithKey is only used to initialize
permissions for a given key and is a no-op if already called with the same key
in a given process. As a result, the following sequence of events could happen:
Assume a content process CP that isn't subscribed to permission changes for an
origin A:
1) Parent process decides to spawn an origin A Service Worker in CP,
snapshotting a value V for permission P.
2) The Service Worker is spawned in CP, setting CP's permission manager's
permission P to value V (for origin A).
3) Parent process updates its permission P to a value A', which is not
broadcasted to CP (because it's not subscribed).
4) By now, the initial Service Worker has been terminated, and the parent
process decides once again to spawn an origin A Service Worker in CP.
5) The Service Worker is spawned in CP, but the call to SetPermissionsWithKey
is a no-op, leaving CP1 with a mismatched value for permission P.
An additional scenario is if the parent process updates a permission during a
remote Service Worker's lifetime.
This patch, which would subscribe CP1 to permission updates when the parent
process knows a Service Worker would be spawned in CP1, prevents these problems.
Differential Revision: https://phabricator.services.mozilla.com/D48620
--HG--
extra : moz-landing-system : lando
Perry Jiang
Narcis Beleuzu
shindli
Dorel Luca
Cosmin Sabou