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
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
The [[nodiscard]] attribute must precede a function declaration's declaration specifiers (like static, extern, inline, or virtual). The __attribute__((warn_unused_result)) attribute does not have this order restriction.
Differential Revision: https://phabricator.services.mozilla.com/D107355
GetValue is going to be removed in a subsequent patch. It is no longer needed,
because it can be replaced by functions already provided by nsBaseHashtable,
in particular Lookup and Contains.
Also, its name was confusing, since it specifically returns a pointer that
allows and is intended for modifying the entry within the hashtable, rather
than returning by-value. According to the naming rules to be set on
nsBaseHashtable, it would also needed to be renamed to "Lookup*. Removing
its uses saves this effort.
Differential Revision: https://phabricator.services.mozilla.com/D105476
This moves parts of IPCMessageUtils.h to two new header files and adapts
the include directives as necessary. The new header files are:
- EnumSerializer.h, which defines the templates for enum serializers
- IPCMessageUtilsSpecializations.h, which defines template specializations
of ParamTraits with extra dependencies (building upon both IPCMessageUtils.h
and EnumSerializer.h)
This should minimize the dependencies pulled in by every consumer of
IPCMessageUtils.h
Differential Revision: https://phabricator.services.mozilla.com/D94459
