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
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
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
This combines the multiple fields or variants which were previously used to
track sided types like protocol types into a single field wrapped with a
SideVariant.
This will be used in the next part to avoid the need for default constructors
for actor types allowing the proper types to be used.
Differential Revision: https://phabricator.services.mozilla.com/D168879
While writing part 1 of this patch, I noticed that the geckoview code
for client.openWindow was returning the outer chrome window's
BrowsingContext rather than the BrowsingContext of the primary content
frame when opening a pop-up window. This meant that the native code
would fail to start navigating the pop-up window (as it would try to
navigate the chrome window which is not allowed).
It turns out the tests were still passing because the geckoview code was
actually starting the load itself, though with the wrong options and
properties. In this patch I remove that call to load a URI from the Java
code, and fix the code in ClientOpenWindowUtils to return the content
BrowsingContext instead of the chrome one.
Differential Revision: https://phabricator.services.mozilla.com/D171756
This makes various changes to the named lookup/navigation code to make
them more precise, and avoid issues which could happen if a window is
closed while script is still executing.
This also should improve handling for inactive windows in some cases, by
more frequently working off of the WindowContext tree rather than the
BrowsingContext tree.
As part of these changes, some behaviour was changed around e.g. the
file URI exception to avoid the deprecated nsIPrincipal::GetURI method.
I don't believe the behaviour should have changed in a meaningful way.
Differential Revision: https://phabricator.services.mozilla.com/D171755
This combines the multiple fields or variants which were previously used to
track sided types like protocol types into a single field wrapped with a
SideVariant.
This will be used in the next part to avoid the need for default constructors
for actor types allowing the proper types to be used.
Differential Revision: https://phabricator.services.mozilla.com/D168879
While writing part 1 of this patch, I noticed that the geckoview code
for client.openWindow was returning the outer chrome window's
BrowsingContext rather than the BrowsingContext of the primary content
frame when opening a pop-up window. This meant that the native code
would fail to start navigating the pop-up window (as it would try to
navigate the chrome window which is not allowed).
It turns out the tests were still passing because the geckoview code was
actually starting the load itself, though with the wrong options and
properties. In this patch I remove that call to load a URI from the Java
code, and fix the code in ClientOpenWindowUtils to return the content
BrowsingContext instead of the chrome one.
Depends on D171755
Differential Revision: https://phabricator.services.mozilla.com/D171756
This makes various changes to the named lookup/navigation code to make
them more precise, and avoid issues which could happen if a window is
closed while script is still executing.
This also should improve handling for inactive windows in some cases, by
more frequently working off of the WindowContext tree rather than the
BrowsingContext tree.
As part of these changes, some behaviour was changed around e.g. the
file URI exception to avoid the deprecated nsIPrincipal::GetURI method.
I don't believe the behaviour should have changed in a meaningful way.
Differential Revision: https://phabricator.services.mozilla.com/D171755
This introduces a new type to ContentParent which acts as a weak handle to the
actor and is safe to hold and manipulate from any thread.
This replaces accesses of the `ContentParent` type from the background thread,
as they were error-prone due to ContentParent not being threadsafe-refcounted.
The bulk of this patch is piping the new type through to the places it is
required, and removing now-unecessary extra complexity.
Differential Revision: https://phabricator.services.mozilla.com/D162346
This is largely a straightforward find and replace of various methods, with the
unnecessary arguments removed and compiler errors fixed.
Differential Revision: https://phabricator.services.mozilla.com/D148532
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
