Unfortunately, upload streams used by necko have various odd behaviours
and requirements which happened to be usually preserved by the previous
IPC serialization logic, but were not consistently preserved. This
includes requiring the stream to be synchronous (as some consumers such
as WebExtensions and DevTools appear to read it assuming Available() is
the stream length), seekable (as it needs to be rewound in various
places), and cloneable (as the stream information is often handed out to
other components).
In addition, the WebExtension WebRequest code makes assumptions about
the specific topology of the input stream for optimization purposes,
meaning that nsMultiplexInputStreams need to be preserved.
The way this was previously handled was by copying the entire payload
into a nsStorageStream as an async operation. This happened very
infrequently in out test suite, however, and had some issues. It could
lead to data loss if the stream was a nsMIMEInputStream (as the metadata
would be lost), and would destroy the topology required by WebRequest.
This patch changes the code to instead manually walk and replace streams
in the input stream's data structure, to efficiently copy only the
required data, preserve the invariants, and make the type seekable
before AsyncOpen continues. This helps keep the complexity of the
invariants HTTPChannel depends on out of generic input stream handling
code.
In addition, due to how early this happens, it replaces the need for
PartiallySeekableInputStream which will be removed a later part.
Differential Revision: https://phabricator.services.mozilla.com/D141044
Unfortunately, upload streams used by necko have various odd behaviours
and requirements which happened to be usually preserved by the previous
IPC serialization logic, but were not consistently preserved. This
includes requiring the stream to be synchronous (as some consumers such
as WebExtensions and DevTools appear to read it assuming Available() is
the stream length), seekable (as it needs to be rewound in various
places), and cloneable (as the stream information is often handed out to
other components).
In addition, the WebExtension WebRequest code makes assumptions about
the specific topology of the input stream for optimization purposes,
meaning that nsMultiplexInputStreams need to be preserved.
The way this was previously handled was by copying the entire payload
into a nsStorageStream as an async operation. This happened very
infrequently in out test suite, however, and had some issues. It could
lead to data loss if the stream was a nsMIMEInputStream (as the metadata
would be lost), and would destroy the topology required by WebRequest.
This patch changes the code to instead manually walk and replace streams
in the input stream's data structure, to efficiently copy only the
required data, preserve the invariants, and make the type seekable
before AsyncOpen continues. This helps keep the complexity of the
invariants HTTPChannel depends on out of generic input stream handling
code.
In addition, due to how early this happens, it replaces the need for
PartiallySeekableInputStream which will be removed a later part.
Differential Revision: https://phabricator.services.mozilla.com/D141044
Unfortunately, upload streams used by necko have various odd behaviours
and requirements which happened to be usually preserved by the previous
IPC serialization logic, but were not consistently preserved. This
includes requiring the stream to be synchronous (as some consumers such
as WebExtensions and DevTools appear to read it assuming Available() is
the stream length), seekable (as it needs to be rewound in various
places), and cloneable (as the stream information is often handed out to
other components).
In addition, the WebExtension WebRequest code makes assumptions about
the specific topology of the input stream for optimization purposes,
meaning that nsMultiplexInputStreams need to be preserved.
The way this was previously handled was by copying the entire payload
into a nsStorageStream as an async operation. This happened very
infrequently in out test suite, however, and had some issues. It could
lead to data loss if the stream was a nsMIMEInputStream (as the metadata
would be lost), and would destroy the topology required by WebRequest.
This patch changes the code to instead manually walk and replace streams
in the input stream's data structure, to efficiently copy only the
required data, preserve the invariants, and make the type seekable
before AsyncOpen continues. This helps keep the complexity of the
invariants HTTPChannel depends on out of generic input stream handling
code.
In addition, due to how early this happens, it replaces the need for
PartiallySeekableInputStream which will be removed a later part.
Differential Revision: https://phabricator.services.mozilla.com/D141044
Unfortunately, upload streams used by necko have various odd behaviours
and requirements which happened to be usually preserved by the previous
IPC serialization logic, but were not consistently preserved. This
includes requiring the stream to be synchronous (as some consumers such
as WebExtensions and DevTools appear to read it assuming Available() is
the stream length), seekable (as it needs to be rewound in various
places), and cloneable (as the stream information is often handed out to
other components).
In addition, the WebExtension WebRequest code makes assumptions about
the specific topology of the input stream for optimization purposes,
meaning that nsMultiplexInputStreams need to be preserved.
The way this was previously handled was by copying the entire payload
into a nsStorageStream as an async operation. This happened very
infrequently in out test suite, however, and had some issues. It could
lead to data loss if the stream was a nsMIMEInputStream (as the metadata
would be lost), and would destroy the topology required by WebRequest.
This patch changes the code to instead manually walk and replace streams
in the input stream's data structure, to efficiently copy only the
required data, preserve the invariants, and make the type seekable
before AsyncOpen continues. This helps keep the complexity of the
invariants HTTPChannel depends on out of generic input stream handling
code.
In addition, due to how early this happens, it replaces the need for
PartiallySeekableInputStream which will be removed a later part.
Differential Revision: https://phabricator.services.mozilla.com/D141044
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
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
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
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
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 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
