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
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
To support foreign partitioned prinicpal for Client, we use
StoragePrincipalHelper::GetPrincipal() to get the foreign partitioned
principal from the channel in the ClientChannelHelper. And use it to
create client.
Differential Revision: https://phabricator.services.mozilla.com/D127631
To support foreign partitioned prinicpal for Client, we use
StoragePrincipalHelper::GetPrincipal() to get the foreign partitioned
principal from the channel in the ClientChannelHelper. And use it to
create client.
Differential Revision: https://phabricator.services.mozilla.com/D127631
To support foreign partitioned prinicpal for Client, we use
StoragePrincipalHelper::GetPrincipal() to get the foreign partitioned
principal from the channel in the ClientChannelHelper. And use it to
create client.
Differential Revision: https://phabricator.services.mozilla.com/D127631
To support foreign partitioned prinicpal for Client, we use
StoragePrincipalHelper::GetPrincipal() to get the foreign partitioned
principal from the channel in the ClientChannelHelper. And use it to
create client.
Differential Revision: https://phabricator.services.mozilla.com/D127631
To support foreign partitioned prinicpal for Client, we use
StoragePrincipalHelper::GetPrincipal() to get the foreign partitioned
principal from the channel in the ClientChannelHelper. And use it to
create client.
Differential Revision: https://phabricator.services.mozilla.com/D127631
To support foreign partitioned prinicpal for Client, we use
StoragePrincipalHelper::GetPrincipal() to get the foreign partitioned
principal from the channel in the ClientChannelHelper. And use it to
create client.
Differential Revision: https://phabricator.services.mozilla.com/D127631
To support foreign partitioned prinicpal for Client, we use
StoragePrincipalHelper::GetPrincipal() to get the foreign partitioned
principal from the channel in the ClientChannelHelper. And use it to
create client.
Differential Revision: https://phabricator.services.mozilla.com/D127631
While investigating an unexpected test failure triggered by a mochitest that was testing the identity WebExtensions API
(D121683 from Bug 1723852) I did notice that the actual underlying issue was triggered by a leak
(in particular the Extension API class in the initial draft of that D121683 patch was missing a RefPtr
in the NS_IMPL_CYCLE_COLLECTION_WRAPPERCACHE macro used for that class) but the issue was presenting
itself as an empty scriptURL in the ClientSource for the test case that was executed after the one that
triggered tha leak, and far enough from where it was actually triggered.
To make it easier to spot the issue nearer to the actual underlying issue, I think that it would be
reasonable to add a diagnostic assertion to ClientManager::GetOrCreateForCurrentThread that would
be triggered earlier if a leak was keeping the ClientManager instance alive in the idle DOM Worker
Thread.
Differential Revision: https://phabricator.services.mozilla.com/D123530
While investigating an unexpected test failure triggered by a mochitest that was testing the identity WebExtensions API
(D121683 from Bug 1723852) I did notice that the actual underlying issue was triggered by a leak
(in particular the Extension API class in the initial draft of that D121683 patch was missing a RefPtr
in the NS_IMPL_CYCLE_COLLECTION_WRAPPERCACHE macro used for that class) but the issue was presenting
itself as an empty scriptURL in the ClientSource for the test case that was executed after the one that
triggered tha leak, and far enough from where it was actually triggered.
To make it easier to spot the issue nearer to the actual underlying issue, I think that it would be
reasonable to add a diagnostic assertion to ClientManager::GetOrCreateForCurrentThread that would
be triggered earlier if a leak was keeping the ClientManager instance alive in the idle DOM Worker
Thread.
Differential Revision: https://phabricator.services.mozilla.com/D123530
We enable this mitigation by default because:
- The alternate UX is about:blank or corrupted content. That's never good.
- We want to make sure that our test coverage handles this mitigation because
it's want we want to ship.
However, we do explicitly disable it for all ServiceWorker WPT's via
`__dir__.ini` directive at the root of the service-workers test tree.
This is motivated by the
`/service-workers/service-worker/update-recovery.https.html` test which
intentionally tests a broken ServiceWorker being able to be updated. It
explicitly tests that the intercepted broken iframe shouldn't successfully
load, but our mitigation makes it load, which breaks the test.
Depends on D111845
Differential Revision: https://phabricator.services.mozilla.com/D111993
We enable this mitigation by default because:
- The alternate UX is about:blank or corrupted content. That's never good.
- We want to make sure that our test coverage handles this mitigation because
it's want we want to ship.
However, we do explicitly disable it for all ServiceWorker WPT's via
`__dir__.ini` directive at the root of the service-workers test tree.
This is motivated by the
`/service-workers/service-worker/update-recovery.https.html` test which
intentionally tests a broken ServiceWorker being able to be updated. It
explicitly tests that the intercepted broken iframe shouldn't successfully
load, but our mitigation makes it load, which breaks the test.
Depends on D111845
Differential Revision: https://phabricator.services.mozilla.com/D111993
The strong reference will be dropped when FutureClientSourceParent is removed,
and we guarantee that all FutureClientSourceParents will either be removed or
replaced with a ClientSourceParent (or at least this is a guarantee that's
supposed to be true).
Differential Revision: https://phabricator.services.mozilla.com/D68041
ClientChannelHelperParent is the thing creating the ClientInfos which aren't
backed by existing ClientSources, so it may make sense for CCHP to tell the
ClientManagerService (CMS) to "expect" or "forget" a "future"
ClientSource(Parent).
When such a ClientInfo is created, CCHP notifies the CMS that a future
ClientSource may be created. This notification has to be observed before any
ClientHandles try to query CMS to a ClientSourceParent, which is the case
because the notification as well as ClientHandleParent constructors occur over
PBackground, and the notification sending method is called first.
CMS is told to forget the future ClientSource whenever a redirect occurs that
would result in the creation of a new ClientSource (i.e. a new ClientInfo). It's
also possible that the ClientInfo's LoadInfo's channel is cancelled. To account
for this, CHCP stores the most recent ClientInfo it's created and tells CMS
to _possibly_ forget the associated future ClientSource in its destructor. It's
possible that the channel completed its load, in which case this notification
is a no-op. This also relies on CHCP being destroyed after the reserved
ClientSource has a chance to both be created and register its
ClientSourceParent.
Differential Revision: https://phabricator.services.mozilla.com/D66529
The changes only make it possible for ClientManagerService to store
FutureClientSourceParents, but it will not actually store them until
following changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66145
Also implements SourceTableEntry and nsIDHasher to switch ClientManagerService's
nsDataHashTable to a mozilla::HashMap<nsID, SourceTableEntry> in following
changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66144
With fission+BFCache, we get a notification for the initial document,
and that fails the same-origin check (because about:blank isn't
same-origin with the opener) so we resolve the promise with null
rather than returning a client.
Instead, wait for the right load to arrive if the top level window
global is the initial document.
Differential Revision: https://phabricator.services.mozilla.com/D112072
With fission+BFCache, we get a notification for the initial document,
and that fails the same-origin check (because about:blank isn't
same-origin with the opener) so we resolve the promise with null
rather than returning a client.
Instead, wait for the right load to arrive if the top level window
global is the initial document.
Differential Revision: https://phabricator.services.mozilla.com/D112072
Cosmin Sabou
Chris Peterson
Tim Huang
Alexandru Michis
Sandor Molnar
Nika Layzell
Butkovits Atila
Cristian Tuns
Noemi Erli
Tom Schuster
Eden Chuang
Luca Greco
Kagami Sascha Rosylight
Iulian Moraru
Andrew Sutherland
Emilio Cobos Álvarez
Simon Giesecke