This is a mechanical change which was performed by a script based on the
contents of direct_call.py, and then manually checked over to fix
various rewriting bugs caused by my glorified sed script. See the
previous part for more context on the change.
Differential Revision: https://phabricator.services.mozilla.com/D137227
Bug 1723674 added a new nsID::GenerateUUID() static factory function to generate UUIDs without the overhead of querying and instantiating an nsIUUIDGenerator object. nsContentUtils::GenerateUUID() is a utility function that amortizes that overhead by holding an nsIUUIDGenerator singleton. That's no longer necessary because code that calls nsContentUtils::GenerateUUID() can now just call nsID::GenerateUUID(). No nsIUUDGenerator is needed.
Differential Revision: https://phabricator.services.mozilla.com/D132866
Since these promises are also holding the GlobalObject(ServiceWorkerGlobalScope), they are needed to be added into the CycleCollection checking.
Otherwise, ServiceWorkerGlobalScope can not be unrooted as expected.
Depends on D133483
Differential Revision: https://phabricator.services.mozilla.com/D136776
#include "mozilla/dom/WorkerScope.h" is removed from WorkerPrivate.h, where calling WorkerPrivate::GlobalScope() without include "WorkerScope.h" makes WorkerScope as an incomplete type.
Depends on 132800
Depends on D132800
Differential Revision: https://phabricator.services.mozilla.com/D133483
Cancel the navigation preload fetching while the FetchEvent has already received Recvdelete or RecvRespondWith
Depends on D129809
Differential Revision: https://phabricator.services.mozilla.com/D130183
This patch defines the interface of FetchService for its consumers.
RefPtr<FetchServiceResponsePromise>&& FetchService::Fetch(SafeRefPtr<InternalRequest> aRequest);
FetchService is a singleton object in the parent process main thread, which is used for managing all the requested fetching created by FetchService.
It would also support more control capability, such as abort or cancel, and also observers for shutdown or other cases. These would be implemented in the following patches.
FetchInstance is an internal representation for each fetching.
Depends on D128465
Differential Revision: https://phabricator.services.mozilla.com/D128223
This patch creates the InternalRequest and sets its Service-Worker-Navigation-Preload header according to the spec step 7.1 and step 7.4
The created InternalRequest is used for passing into FetchService to perform fetch in the parent process for NavigationPreload API.
Differential Revision: https://phabricator.services.mozilla.com/D128465
This patch includes a set of changes to the ServiceWorker internals to introduce a new
nsIServiceWorkerManager.wakeForExtensionAPIEvent method, to be used by the WebExtensions internals
to request an active background service worker to be spawned (if it is not yet) in response to
a WebExtension API event.
The new method gets as parameters:
- the scope URL for the extension background service worker to spawn
- WebExtensions API namespace and API event name which we are going to spawn an active worker for
and return a promise which would be:
- rejected if the worker could not be spawned
- resolved to a boolean if the worker was spawned successfully (or already running)
The value of the boolean value resolved is meant to represent if the worker did actually
have any listener subscribed for the given WebExtensions API event listener
(which the WebExtensions internals may then use to decide if it is worth to send that event
to be handled by the worker script or not).
In this patch the ExtensionBrowser::HasWakeupEventListener used to determine if an WebExtensions
API event was subscribed syncronously when the worker was being loaded is not implemented yet
and it is always returning false (a proposed implementation for that method is going to be
added in a separate patch part of this same bugzilla issue).
A unit test for the new proposed nsIServiceWorkerManager method is also part of a separate patch
(attached to this bugzilla issue as the child revision for this one).
Differential Revision: https://phabricator.services.mozilla.com/D130756
#include "mozilla/dom/WorkerScope.h" is removed from WorkerPrivate.h, where calling WorkerPrivate::GlobalScope() without include "WorkerScope.h" makes WorkerScope as an incomplete type.
Depends on 132800
Depends on D132800
Differential Revision: https://phabricator.services.mozilla.com/D133483
We want to record the number of registered and running ServiceWorkers, and
subset them by whether they support Fetch or not, in order to inform
decisions about isolating ServiceWorkers.
Also reenables some of the other ServiceWorker telemetry we used to collect
until FF 102
Differential Revision: https://phabricator.services.mozilla.com/D131563
We want to record the number of registered and running ServiceWorkers, and
subset them by whether they support Fetch or not, in order to inform
decisions about isolating ServiceWorkers.
Also reenables some of the other ServiceWorker telemetry we used to collect
until FF 102
Differential Revision: https://phabricator.services.mozilla.com/D131563
Bug 1723674 added a new nsID::GenerateUUID() static factory function to generate UUIDs without the overhead of querying and instantiating an nsIUUIDGenerator object. nsContentUtils::GenerateUUID() is a utility function that amortizes that overhead by holding an nsIUUIDGenerator singleton. That's no longer necessary because code that calls nsContentUtils::GenerateUUID() can now just call nsID::GenerateUUID(). No nsIUUDGenerator is needed.
Differential Revision: https://phabricator.services.mozilla.com/D132866
We want to record the number of registered and running ServiceWorkers, and
subset them by whether they support Fetch or not, in order to inform
decisions about isolating ServiceWorkers.
Also reenables some of the other ServiceWorker telemetry we used to collect
until FF 102
Differential Revision: https://phabricator.services.mozilla.com/D131563
We want to record the number of registered and running ServiceWorkers, and
subset them by whether they support Fetch or not, in order to inform
decisions about isolating ServiceWorkers.
Also reenables some of the other ServiceWorker telemetry we used to collect
until FF 102
Differential Revision: https://phabricator.services.mozilla.com/D131563
This patch enables partitioned service workers in third-party contexts.
Doesn't like before, we will allow service workers to be registered even
the third-party contexts don't have storage access and the registered
service workers will be partitioned by the top-level site.
You can control this by using the pref 'privacy.partition.serviceWorkers'.
Setting this to true will enable the partitioning, otherwise, it will
still use the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131788
This patch changes ServiceWorkerScriptCache to use the principal of the
service worker to populate the partitionKey to the cookieJarSettings.
The service workers are using foreign partitioned principal. This means
it will contain a correct partitionKey if it's in a third-party context.
So we can use it to populate the partitionKey. In the first-party
context, we can use the script uri to get the partionKey, which is the
original approach.
Differential Revision: https://phabricator.services.mozilla.com/D128734
We used to use the principal URL for the partitionKey in
ServiceWorkerPrivateImpl. This is correct if the ServiceWorker only
works in first-party context. But, it isn't correct in third-party
context.
To fix that, we can directly use the foreign paritioned principal from
the ServiceWorkerPrivate to get the partitionKey in third-party context.
For the first-party context, we can still use the original approach to
get the partitionKey.
Differential Revision: https://phabricator.services.mozilla.com/D128733
This patch changes to use the foreign partitioned principal when check
if a channel needs to be intercepted by a certain service worker.
Differential Revision: https://phabricator.services.mozilla.com/D128731
To know if a worker is created under a third-party context, we need to
populate the `IsThirdPartyContextToTopWindow` to WorkerPrivate. This is
needed to get the correct foreign partitioned prinipal when loading
worker script in the content processes.
Differential Revision: https://phabricator.services.mozilla.com/D129059
Currently, the ServiceWorkerManager creates a content prinipcal based
on the regular originAttributes when dispatch the fetch event. This
patch changes to use the foreign partitioned originAttributs.
Note that we don't add tests for this because the change doesn't change
the behavior. And we don't enable partitioned third-party Service Worker.
So, the existing test cases is enough for this.
Differential Revision: https://phabricator.services.mozilla.com/D127632
A previous patch added code paths that propagate the preload response
from the parent process's main thread to the service worker in the
content process, but left out the conversions between different stream
types. This commit adds these conversions.
Based on D122822.
Differential Revision: https://phabricator.services.mozilla.com/D131380
This commit replaces IPCInternalResponse with three different structs:
ParentToParentInternalResponse, ParentToChildInternalResponse, and
ChildToParentInternalResponse. Doing this lets us convert runtime
checks into compile-time type checks and simplifies relevant code.
Differential Revision: https://phabricator.services.mozilla.com/D131275
Annotating each test individually lets us avoid introducing new failing tests
while we go through the backlog of failing tests.
Depends on D129162
Differential Revision: https://phabricator.services.mozilla.com/D129163
Annotating each test individually lets us avoid introducing new failing tests
while we go through the backlog of failing tests.
Depends on D129162
Differential Revision: https://phabricator.services.mozilla.com/D129163
In order to support running service worker tests for dFPI, we first
convert the existing mochitest.ini, chrome.ini and browser.ini to
mochitest-common.ini, chrome-common.ini and browser-common.ini respectively.
And create ini files that import them.
Differential Revision: https://phabricator.services.mozilla.com/D130745
This patch implements the IPC for propagating the preload response from the parent process' main thread to the content process' worker thread.
The following is the complicated propagation path.
FetchEventOpChild(Parent process main thread) =>
FetchEventOpParent(Parent process background thread) =>
FetchEventOpProxyParent(Parent process background thread) =>
FetchEventOpProxyChild(content process worker launch thread) =>
ServiceWorker(content process worker thread)
However, since preload response fetching is an asynchronous behavior, the preload response can be ready at any time point during the fetch event dispatching. This patch also handles different situations. Basically, it can be separated into the following stages.
1. Preload response is ready when the fetch event dispatching is in the parent process main thread, which means the fetch event is pending as a ServiceWorkerPrivateImpl::PendingFetchEvent. Details in PendingFetchEvent and FetchEventOpChild
2. Preload response is ready when the fetch event dispatching is in the parent process background thread, which means fetch event is still waiting for worker launching. Details in FetchEventOpParent and FetchEventOpProxyParent.
3. Preload response is ready when constructing the fetch event. Details in FetchEventOpProxyChild and ServiceWorkerOp::FetchEventOp.
Depends on D126244
Differential Revision: https://phabricator.services.mozilla.com/D122821
To know if a worker is created under a third-party context, we need to
populate the `IsThirdPartyContextToTopWindow` to WorkerPrivate. This is
needed to get the correct foreign partitioned prinipal when loading
worker script in the content processes.
Differential Revision: https://phabricator.services.mozilla.com/D129059
Currently, the ServiceWorkerManager creates a content prinipcal based
on the regular originAttributes when dispatch the fetch event. This
patch changes to use the foreign partitioned originAttributs.
Note that we don't add tests for this because the change doesn't change
the behavior. And we don't enable partitioned third-party Service Worker.
So, the existing test cases is enough for this.
Differential Revision: https://phabricator.services.mozilla.com/D127632
This patch introduces a new getRegistrationForAddonPrincipal to nsIServiceWorkerManager.
This method is similar to the existing getRegistrationForPrincipal but:
- similarly to registerForAddonPrincipal it only gets the extension principal as its only
input parameter.
- unlike getRegistrationForPrincipal, it doesn't throw if the registration has not been found
(e.g. because it was already unregistered when the method was called).
Differential Revision: https://phabricator.services.mozilla.com/D124702
This patch introduces a new getRegistrationForAddonPrincipal to nsIServiceWorkerManager.
This method is similar to the existing getRegistrationForPrincipal but:
- similarly to registerForAddonPrincipal it only gets the extension principal as its only
input parameter.
- unlike getRegistrationForPrincipal, it doesn't throw if the registration has not been found
(e.g. because it was already unregistered when the method was called).
Differential Revision: https://phabricator.services.mozilla.com/D124702
Currently, the ServiceWorkerManager creates a content prinipcal based
on the regular originAttributes when dispatch the fetch event. This
patch changes to use the foreign partitioned originAttributs.
Note that we don't add tests for this because the change doesn't change
the behavior. And we don't enable partitioned third-party Service Worker.
So, the existing test cases is enough for this.
Differential Revision: https://phabricator.services.mozilla.com/D127632
Currently, the ServiceWorkerManager creates a content prinipcal based
on the regular originAttributes when dispatch the fetch event. This
patch changes to use the foreign partitioned originAttributs.
Note that we don't add tests for this because the change doesn't change
the behavior. And we don't enable partitioned third-party Service Worker.
So, the existing test cases is enough for this.
Differential Revision: https://phabricator.services.mozilla.com/D127632
Currently, the ServiceWorkerManager creates a content prinipcal based
on the regular originAttributes when dispatch the fetch event. This
patch changes to use the foreign partitioned originAttributs.
Note that we don't add tests for this because the change doesn't change
the behavior. And we don't enable partitioned third-party Service Worker.
So, the existing test cases is enough for this.
Differential Revision: https://phabricator.services.mozilla.com/D127632
Currently, the ServiceWorkerManager creates a content prinipcal based
on the regular originAttributes when dispatch the fetch event. This
patch changes to use the foreign partitioned originAttributs.
Note that we don't add tests for this because the change doesn't change
the behavior. And we don't enable partitioned third-party Service Worker.
So, the existing test cases is enough for this.
Differential Revision: https://phabricator.services.mozilla.com/D127632
Currently, the ServiceWorkerManager creates a content prinipcal based
on the regular originAttributes when dispatch the fetch event. This
patch changes to use the foreign partitioned originAttributs.
Note that we don't add tests for this because the change doesn't change
the behavior. And we don't enable partitioned third-party Service Worker.
So, the existing test cases is enough for this.
Differential Revision: https://phabricator.services.mozilla.com/D127632
The goal here is to ensure we can always rely on `AppShutdown::GetShutdownPhase` to be in sync with the "real" application status, mainly this was needed for xpcshell tests to not break if we add assertions on our shutdown state on some global singletons.
We keep the existing observer notification topics but force them (on the parent process) to be issued through the new `advanceShutdownPhase` function of the startup service using the `ShutdownPhase` enum. This way we can synchronize `AppShutdown`'s internal status accordingly.
Some further notes:
# The `MOZ_ASSERT(AppShutdown::IsNoOrLegalShutdownTopic(aTopic));` in `NotifyObservers` helped a lot to identify missing cases. I think we should keep it in order to stay safe.
# Introducing the `cenum IDLShutdownPhase` helps to keep the knowledge about the mapping from shutdown phases to observer topics exclusively inside AppShutdown.cpp. Still callers must know what they do in order to choose a proper phase, of course.
# However we must be aware that `AppShutdown` this way can be kept in sync with the shutdown notifications only in the parent process and that `GetCurrentShutdownPhase` might not give the correct result in child processes. We might want to file a follow up bug that adds some asserts to avoid improper use of `AppShutdown` functions in child processes (but I do not want to make this patch bigger as needed to solve the blocking dependency for bug 1697972).
# The socket process is one example of a child process that "overloads" shutdown topics. I was wondering if it is the right call to use the very same topic names here to request shutdown to the socket process or if it should have its own topics. Those topics triggered the assert and thus I had to disable it for child processes, for now.
# This goes together with the more general approach to define process type specific shutdown phases (and hence mappings to topics) as drafted very roughly in bug 1697745.
# This patch seemed to trigger a known intermittent more often, thus the change here in `ServiceWorkerManager`.
Differential Revision: https://phabricator.services.mozilla.com/D124350
This commit modifies test_interfaces.js to also test the exposed interfaces
in the WebAssembly namespace. We have conditional features that we'd like
to have confidence that we're not accidentally exposing to web content.
Currently there are:
* WebAssembly exceptions, enabled only in nightly with a default-off pref
* mozIntGemm accelerator function, available only in system or addon principals
Depends on D120731
Differential Revision: https://phabricator.services.mozilla.com/D120732
This patch introduces ServiceWorkerQuotaUtils.h, which provides helper methods related nsIQuotaManagerService and nsIClearDataService.
QuotaUsageChecker implements the quota usage checking algorithm.
1. Getting the given origin/group usage through QuotaManagerService. QuotaUsageCheck::Start() implements this step.
2. Checking if the group usage headroom(gGroupUsageHeadRoom) is satisfied. It could be following three situations. a. Group headroom is satisfied without any usage mitigation. b. Group headroom is satisfied after origin usage mitigation. This invokes nsIClearDataService::DeleteDataFromPrincipal(). c. Group headroom is satisfied after group usage mitigation. This invokes nsIClearDataService::DeleteDataFromBaseDomain().
QuotaUsageChecker::CheckQuotaHeadRoom() implements this step.
If the algorithm is done or error out, the QuotaUsageCheck::mCallback will be called with a bool result for external handling.
Depends on D122188
Differential Revision: https://phabricator.services.mozilla.com/D122189
This patch implements methods for ServiceWorkerRegistrationInfo to invoke the quota usage checking.
ServiceWorkerRegistrationInfo::CheckQuotaUsage() is an internal using method, such that it is a private method.
Differential Revision: https://phabricator.services.mozilla.com/D120964
This patch introduces ServiceWorkerQuotaUtils.h, which provides helper methods related nsIQuotaManagerService and nsIClearDataService.
QuotaUsageChecker implements the quota usage checking algorithm.
1. Getting the given origin/group usage through QuotaManagerService. QuotaUsageCheck::Start() implements this step.
2. Checking if the group usage headroom(gGroupUsageHeadRoom) is satisfied. It could be following three situations. a. Group headroom is satisfied without any usage mitigation. b. Group headroom is satisfied after origin usage mitigation. This invokes nsIClearDataService::DeleteDataFromPrincipal(). c. Group headroom is satisfied after group usage mitigation. This invokes nsIClearDataService::DeleteDataFromBaseDomain().
QuotaUsageChecker::CheckQuotaHeadRoom() implements this step.
If the algorithm is done or error out, the QuotaUsageCheck::mCallback will be called with a bool result for external handling.
Depends on D122188
Differential Revision: https://phabricator.services.mozilla.com/D122189
This patch implements methods for ServiceWorkerRegistrationInfo to invoke the quota usage checking.
ServiceWorkerRegistrationInfo::CheckQuotaUsage() is an internal using method, such that it is a private method.
Differential Revision: https://phabricator.services.mozilla.com/D120964
This patch tries to record the fetch event dispatching time, the response's synthesizing time, and interception resetting time.
Fetch event dispatching time is the time duration between interception starts, which is the time point of InterceptedHttpChannel::AsyncOpenInternal(), and the fetch handler starts. It includes the InterceptedHttpChannel setup time, ServiceWorker launch time, FetchEventOp propagation through IPC, a FetchEvent creation, initialization, and dispatching/scheduling on worker scope.
Response synthesizing time is the time duration between the fetch handler finishes, which is the resolving/rejecting promise of respondWith(), to the finish of pumping the synthesized response to InterceptedHttpChannel, which is the time point of calling InterceptedHttpChannel::OnStopRequest(). It includes the response propagation through IPC, response header and body synthesis, and pumping synthesized response to the channel.
Interception resetting time is the time duration between the fetch handler finishes and redirecting InterceptedHttpChannel to a normal HTTP channel.
Since the fetch handler is executed on the process where the service worker spawned, the timestamps related to the fetch handler need to be get on that process. So this patch adds the FetchHandlerStart and FetchHandlerFinish on IPCFetchEventRespondWithResult related types to propagate the timestamps to the parent process.
Depends on D118398
Differential Revision: https://phabricator.services.mozilla.com/D118399
Instead of recording service workers' spawning in InterceptedHttpChannel, recording SERVICE_WORKER_LAUNCH_TIME_2 in ServiceWorkerPrivateImpl since spawning does not happen in fetch only
Depends on D118396
Differential Revision: https://phabricator.services.mozilla.com/D118397
This patch introduce an additional xpcshell test task (built on top of the other one added in D119799)
which cover explicitly the following behaviors:
- the extension service worker registrations are expected to:
- not be unregistered if the addon is shutting down as part of the application shutdown
- to be unregistered if the addon is disabled (while the application is not shutting down)
- the extension service worker is expected to:
- receive the "install" and "activate" lifecycle events when the service worker is registered for the first time
or if the addon is disabled and then re-enabled while the application is not shutting down
- not receive the "install" and "activate" lifecycle events when a previously active worker
is spawned again (in particular after the entire application is restarted)
Ideally these behavior shoud be tested by restarting the browser instance as in a real Browser instance
but asserting all these behavior from a marionette test would be a bit trickier (but I still plan to
take a look into that, at least to cover with a marionette test a subset of the expected behaviors on
browser restart).
As an additional side note, the test case introduced in this test is currently assuming that we
may not proceed with D119531, and so to avoid to hit the issue described in that patch description
this patch is currently introducing an additional test-only method to nsIServiceWorkerManager
(named reloadRegistrationsForTest) which currently does the bare minimum to mock the "Browser restart"
scenario.
If on the contrary, we decide to proceed further with D119531, the new nsIServiceWorkerManager.reloadRegistrationsForTest
helper would not be needed anymore (because we would just use the existing ServiceWorkerRegistrationInfo instance which
is basically in the same state that the new one loaded from the ServiceWorkerRegistar would be, besides the issue with the
stale WebExtensionPolicy instance stored in the principal associated to the previous service worker registration).
Differential Revision: https://phabricator.services.mozilla.com/D120351
This patch does prevent a service worker previously registered by a webextension to be spawned
if the webextension isn't enabled.
Instead of marking the service worker as disabled (e.g. as part of the registration data that we
store on disk), this patch is currently adding an additional check in
ServiceWorkerPrivateImpl::SpawnIfNeeded to make it early exit with an error if:
- the worker principal has a moz-extension url
- and it does not have a WebExtensionPolicy or the WebExtensionPolicy is not active
(which would mean that the extension was being uninstalled or disabled)
Differential Revision: https://phabricator.services.mozilla.com/D119532
Eden Chuang
Marian-Vasile Laza
Kagami Sascha Rosylight
Sylvestre Ledru
Karl Dubost
Randell Jesup
Nika Layzell
criss
Andreea Pavel
Chris Peterson
Ryan Hunt
Matthew Gaudet
Jens Stutte
Norisz Fay
Csoregi Natalia
Gijs Kruitbosch
Andrew Osmond
Luca Greco
Gabriele Svelto
Dragana Damjanovic
Cosmin Sabou
Alexandru Michis
Tim Huang
Yaron Tausky
Niklas Goegge
ssummar
Cristian Tuns
Evgenia Kotovich
Butkovits Atila
Joel Maher
Noemi Erli
Molly Howell
Tom Schuster
Sandor Molnar
Michelle Goossens
Florian Quèze
Steve Fink
Iulian Moraru
Andi-Bogdan Postelnicu
Christoph Kerschbaumer
Kashav Madan