Bug 1544232 changed it so ServiceWorker globals used a ClientInfo and
Client Id created by the ServiceWorkerPrivate rather than creating a
random client id. This allows the ServiceWorkerManager to reliably map
a ServiceWorker Client Id back to the underlying ServiceWorker.
The problem with this was that ClientManagerService is not okay with
there being multiple ClientSources using the same id and it results in
an IPC_FAIL. This was not a problem in desktop testing because under
fission the potential race window is incredibly small for a
ServiceWorker and its spawned successor to have a live ClientSource at
the same time because the ClientSource will be torn down by the
ClientManager WorkerRef on the transition to canceling and both SWs
will be spawned in the same process. But on Android where there is no
fission, SWs spawn randomly with no affinity and so a successor can be
spawned on a different, more responsive process.
The fix here is to regenerate the Client Id whenever we terminate the
SW so we are prepared for the next time we spawn the SW.
This patch adds an additional test case to
browser_sw_lifetime_extension.js that is able to reproduce the crash
case on desktop by artificially blocking the ServiceWorker thread with
a monitor so that the ServiceWorker can't transition to Canceling until
its successor has already been spawned. This reliably reproduces the
bug (when the fix is not in place). This required adding some new test
infrastructure to WorkerTestUtils.
The new WorkerTestUtils methods provide 2 ways to hang the worker in a
controlled fashion until an observer notification is notified on the
main thread which use a shared helper class:
1. Use a monitor to completely block the thread until notified. This
prevents control runnables from running and thereby prevents worker
refs from being notified.
2. Acquire a ThreadSafeWorkerRef and hold it until notified. This lets
the worker advance to Canceling but prevents progressing to Killing.
I added the WorkerRef mechanism first but it wasn't sufficient, so I
added the monitor mechanism, slightly generalizing the mechanism.
A mechanism to generate an observer notification on the main thread is
also added so that the successor ServiceWorker can notify the
predecessor SW without us needing to involve JSActors or other means
of running arbitrary JS in the process hosting the SWs. This does mean
that when we are in non-fission mode we do need to limit the browser to
a single process in order to ensure both workers are spawned in the
same process.
Differential Revision: https://phabricator.services.mozilla.com/D227446
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
This patch introduces an explicit concept of lifetimes with mechanisms
in place so that actions taken by Clients (windows or non-ServiceWorker
orkers) will extend the lifetime of a ServiceWorker, but a ServiceWorker
cannot extend the life of another ServiceWorker.
The areas of concern are:
- ServiceWorker.postMessage: With ServiceWorkers exposed on workers and
the ability to access other registrations via ServiceWorkerContainer
being exposed, ServiceWorkers can message other ServiceWorkers. It's
essential that they never be allowed to give a ServiceWorker a
lifetime longer than their own.
- ServiceWorkerRegistration.update(): Requesting an update of a
registration should not allow any installed/updated ServiceWorker to
have a lifetime longer than the ServiceWorker creating the request.
- ServiceWorkerContainer.register(): Requesting the installation of a
new ServiceWorker should likewise constrain the lifetime of the newly
installed ServiceWorker.
Note that in cases where we would potentially spawn a ServiceWorker,
whether it be in response to postMessage or as part of an install or
update, a key criteria is whether the lifetime extends far enough into
the future for us to believe the ServiceWorker can accomplish anything.
Currently we have a constant of 5 seconds against a normal full
lifetime of 30 seconds (before 30 second grace period). So once a SW
has < 5 seconds of lifetime left, it won't be able to spawn a SW. Note
that in the case of install/update, we do not prevent the creation of
the job at this time, instead the job will fail during the check script
evaluation step as failure to spawn the ServiceWorker is equivalent to
a script load failure.
A somewhat ugly part of this implementation is that because Bug 1853706
is not yet implemented, our actors that are fundamentally associated
with a global don't have an inherent understanding of their relationship
to that global. So we approximate that by:
- For postMessage, we always have a ServiceWorkerDescriptor if we are
being messaged by a ServiceWorker, allowing us direct lookup.
- ServiceWorkerRegistration.update(): In a previous patch in the stack
we had ServiceWorkerRegistrationProxy latch the ClientInfo of its
owning global when it was created. Note that in the case of a
ServiceWorker's own registration, this will be created at startup
before the worker hits the execution ready state.
- Note that because we have at most one live
ServiceWorkerRegistration per global at a time, and the
registration is fundamentally associated with the
ServiceWorkerGlobalScope, that registration and its proxy will
remain alive for the duration of the global.
- ServiceWorkerContainer.register(): We already were sending the client
info along with the register call (as well as all other calls on the
container).
Looking up the ServiceWorker from its client is not something that was
really intended. This is further complicated by ServiceWorkerManager
being authoritative for ServiceWorkers on the parent process main thread
whereas the ClientManagerService is authoritative on PBackground and
actor-centric, making sketchy multi-threaded maps not really an option.
Looking up the ServiceWorker from a ServiceWorkerDescriptor is intended,
but the primary intent in those cases is so that the recipient of such a
descriptor can easily create a ServiceWorker instance that is
live-updating (by way of its owning ServiceWorkerRegistration; we don't
have IPC actors directly for ServiceWorkers, just the registration).
Adding the descriptor to clients until Bug 1853706 is implemented would
be an exceedingly ugly workaround because it would greatly complicate
the existing plumbing code, and a lot of the code is confusing enough
as-is.
This patch initially adopted an approach of encoding the scope of a
ServiceWorker as its client URL, but it turns out web extension
ServiceWorker support (reasonably) assumed the URL would be the script
URL so the original behavior was restored and when performing our
lookup we just check all registrations associated with the given
origin. This is okay because register and update calls are inherently
expensive, rare operations and the overhead of the additional checks is
marginal. Additionally, we can remove this logic once Bug 1853706 is
implemented.
As part of that initial scope tunneling was that, as noted above, we
do sample the ClientInfo for a ServiceWorker's own registration before
the worker is execution-ready. And prior to this patch, we only would
populate the URL during execution-ready because for most globals, we
can't possibly know the URL when the ClientSource is created. However,
for ServiceWorkers we can. Because we also want to know what the id of
the ServiceWorker client would be, we also change the creation of the
ServiceWorker ClientSource so that it uses a ClientInfo created by the
authoritative ServiceWorkerPrivate in its Initialize method.
A minor retained hack is that because the worker scriptloader propagates
its CSP structure onto its ClientInfo (but not its ClientSource, which
feels weird, but makes sense) and that does get sent via register(), we
do also need to normalize the ClientInfo in the parent when we do
equality checking to have it ignore the CSP.
Differential Revision: https://phabricator.services.mozilla.com/D180915
This will enable propagating lifetime deadlines based on the deadline
of the client calling ServiceWorkerRegistration.update in the
subsequent patch.
Note that the data-flow of the Client here differs from
ServiceWorkerContainer::Register propagating the ClientInfo to
ServiceWorkerManager::Register. In that case, the binding samples the
client at call-time and propagates it over the register IPC call rather
than during the construction of the PServiceWorkerContainer actor.
This change in approach is to align with Bug 1853706 wherein we plan to
associate the actors strictly to the global.
Differential Revision: https://phabricator.services.mozilla.com/D196702
This corrects a longstanding race in our updatefound logic and makes
testing/web-platform/tests/service-workers/service-worker/ServiceWorkerGlobalScope/registration-attribute.https.html
consistently pass. (Other patches in this stack made the test no
longer permafail and removed the meta .ini, but surfaced the race.)
https://bugzilla.mozilla.org/show_bug.cgi?id=1257977#c12 provides
detailed context, but the basic idea is that bug 1510809 cleaned up
our updatefound logic but left a runnable delay introduced in
bug 1471929 that made sense for the fix there, but stopped making sense
with bug 1510809.
This fix repurposes the FireUpdateFound() method declaration that had
no actual implementing method to call into the private
MaybeDispatchUpdateFound which is part of a sufficiently confusing
internal state machine that it makes sense to leave it private and use
a more sane public name.
Differential Revision: https://phabricator.services.mozilla.com/D213726
ServiceWorkers aren't exposed as clients, so when we are sending a postMessage
from them, we need to capture their ServiceWorkerDescriptor and propagate that
instead of the client state.
Differential Revision: https://phabricator.services.mozilla.com/D213721
We are able to remove ServiceWorkerVisible and instead use
ServiceWorkersEnabled in its place since we are no longer limiting
where ServiceWorker instances are exposed.
The correctness of ExtendableMessageEvent.source is addressed later in
the stack.
Although we enable skip-waiting-installed.https.html here, we also have
to make it expected it will sometimes fail due to an inherent IPC race;
bug 1926641 describes the situation.
Differential Revision: https://phabricator.services.mozilla.com/D180914
This commit exposes the Permissions API to DOM Workers. It achieves this goal
by introducing a thread-safe bridge between `PermissionStatus` and the
`PermissionObserver`: the `PermissionStatusSink` object.
Actors:
- The `PermissionObserver` is a main-thread-only singleton that monitors
permission change events and propagates the notification to the right sink
objects.
- The `PermissionStatus` is the DOM object exposed to the global. It's not
thread-safe.
- The `PermissionStatusSink` is the new bridge introduced by this commit.
The `PermissionStatusSink` lifetime:
- This object is kept alive on the current thread by the `PermissionStatus` and
on the main thread by the `PermissionObserver`.
- The `PermissionStatus` creates the object on its creation thread. When
`PermissionStatus` object is released (or disconnected from the owner, it
disentangles itself from the `PermissionStatusSink`. The disentangle
operation triggers the un-registration procedure from the
`PermissionObserver` on the main thread.
- A weak `WorkerRef` is used to monitor the worker's lifetime.
Permission change notification:
- When the `PermissionObserver` is notified for a permission-change event, it
notifies all the `PermissionStatusSink`. This happens on the main thread (see
`MaybeUpdatedByOnMainThread` and `MaybeUpdatedByNotifyOnlyOnMainThread`).
- Using `MozPromise`, the `PermissionStatusSink` computes the permission action
(`PermissionChangedOnMainThread`) on the main thread, then informs the
parent `PermissionStatus` object on its creation thread.
- The `PermissionStatus` object converts the action to the DOM
`PermissionState` and dispatches an event.
Differential Revision: https://phabricator.services.mozilla.com/D224594
This commit exposes the Permissions API to DOM Workers. It achieves this goal
by introducing a thread-safe bridge between `PermissionStatus` and the
`PermissionObserver`: the `PermissionStatusSink` object.
Actors:
- The `PermissionObserver` is a main-thread-only singleton that monitors
permission change events and propagates the notification to the right sink
objects.
- The `PermissionStatus` is the DOM object exposed to the global. It's not
thread-safe.
- The `PermissionStatusSink` is the new bridge introduced by this commit.
The `PermissionStatusSink` lifetime:
- This object is kept alive on the current thread by the `PermissionStatus` and
on the main thread by the `PermissionObserver`.
- The `PermissionStatus` creates the object on its creation thread. When
`PermissionStatus` object is released (or disconnected from the owner, it
disentangles itself from the `PermissionStatusSink`. The disentangle
operation triggers the un-registration procedure from the
`PermissionObserver` on the main thread.
- A weak `WorkerRef` is used to monitor the worker's lifetime.
Permission change notification:
- When the `PermissionObserver` is notified for a permission-change event, it
notifies all the `PermissionStatusSink`. This happens on the main thread (see
`MaybeUpdatedByOnMainThread` and `MaybeUpdatedByNotifyOnlyOnMainThread`).
- Using `MozPromise`, the `PermissionStatusSink` computes the permission action
(`PermissionChangedOnMainThread`) on the main thread, then informs the
parent `PermissionStatus` object on its creation thread.
- The `PermissionStatus` object converts the action to the DOM
`PermissionState` and dispatches an event.
Differential Revision: https://phabricator.services.mozilla.com/D224594
This commit exposes the Permissions API to DOM Workers. It achieves this goal
by introducing a thread-safe bridge between `PermissionStatus` and the
`PermissionObserver`: the `PermissionStatusSink` object.
Actors:
- The `PermissionObserver` is a main-thread-only singleton that monitors
permission change events and propagates the notification to the right sink
objects.
- The `PermissionStatus` is the DOM object exposed to the global. It's not
thread-safe.
- The `PermissionStatusSink` is the new bridge introduced by this commit.
The `PermissionStatusSink` lifetime:
- This object is kept alive on the current thread by the `PermissionStatus` and
on the main thread by the `PermissionObserver`.
- The `PermissionStatus` creates the object on its creation thread. When
`PermissionStatus` object is released (or disconnected from the owner, it
disentangles itself from the `PermissionStatusSink`. The disentangle
operation triggers the un-registration procedure from the
`PermissionObserver` on the main thread.
- A weak `WorkerRef` is used to monitor the worker's lifetime.
Permission change notification:
- When the `PermissionObserver` is notified for a permission-change event, it
notifies all the `PermissionStatusSink`. This happens on the main thread (see
`MaybeUpdatedByOnMainThread` and `MaybeUpdatedByNotifyOnlyOnMainThread`).
- Using `MozPromise`, the `PermissionStatusSink` computes the permission action
(`PermissionChangedOnMainThread`) on the main thread, then informs the
parent `PermissionStatus` object on its creation thread.
- The `PermissionStatus` object converts the action to the DOM
`PermissionState` and dispatches an event.
Differential Revision: https://phabricator.services.mozilla.com/D224594
- Renames deleteDataFromBaseDomain to deleteDataFromSite.
- Cleans up terminology for (schemeless site) to better align with standards.
- deleteDataFromSite requires a schemeless site to be passed in. We will no longer
implicitly convert the host to a site.
- Removes the host fallback for SiteDataManager and ForgetAboutSite. The new schemeless site
helper Services.eTLD.getSchemelessSiteFromHost accounts for this.
Differential Revision: https://phabricator.services.mozilla.com/D220605
- Renames deleteDataFromBaseDomain to deleteDataFromSite.
- Cleans up terminology for (schemeless site) to better align with standards.
- deleteDataFromSite requires a schemeless site to be passed in. We will no longer
implicitly convert the host to a site.
- Removes the host fallback for SiteDataManager and ForgetAboutSite. The new schemeless site
helper Services.eTLD.getSchemelessSiteFromHost accounts for this.
Differential Revision: https://phabricator.services.mozilla.com/D220605
- Renames deleteDataFromBaseDomain to deleteDataFromSite.
- Cleans up terminology for (schemeless site) to better align with standards.
- deleteDataFromSite requires a schemeless site to be passed in. We will no longer
implicitly convert the host to a site.
- Removes the host fallback for SiteDataManager and ForgetAboutSite. The new schemeless site
helper Services.eTLD.getSchemelessSiteFromHost accounts for this.
Differential Revision: https://phabricator.services.mozilla.com/D220605
- Renames deleteDataFromBaseDomain to deleteDataFromSite.
- Cleans up terminology for (schemeless site) to better align with standards.
- deleteDataFromSite requires a schemeless site to be passed in. We will no longer
implicitly convert the host to a site.
- Removes the host fallback for SiteDataManager and ForgetAboutSite. The new schemeless site
helper Services.eTLD.getSchemelessSiteFromHost accounts for this.
Differential Revision: https://phabricator.services.mozilla.com/D220605
Andrew Sutherland
serge-sans-paille
Joel Maher
Alexandru Marc
Andrea Marchesini
Stanca Serban
Butkovits Atila
Tamas Szentpeteri
Mike Hommey
smayya
Paul Zuehlcke
Fatih
Eden Chuang
Norisz Fay
Florian Quèze
Benjamin VanderSloot
Iulian Moraru