The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
Because we would check the storage access permission inside
nsGlobalWindowInner::ExecutionReady(), so we need to set the
'HasStoragePermission' flag before we call it in
nsGlobalWindowOuter::SetNewDocument().
In addition, we check the assertion in the
ClientSource::WindowExecutionReady() back to a diagnostic assertion.
Depends on D71564
Differential Revision: https://phabricator.services.mozilla.com/D71565
We change this assertion to a normal to ease the crash problem from
users and will do a further investigation to know the root cause.
Differential Revision: https://phabricator.services.mozilla.com/D71525
This is a temporary solution as we don't want to permanently override users'
preferences.
Differential Revision: https://phabricator.services.mozilla.com/D70761
--HG--
extra : moz-landing-system : lando
This patch also tries to remove the event target entirely if it would
default to the main thread on a null event target.
Depends on D67634
Differential Revision: https://phabricator.services.mozilla.com/D67635
--HG--
extra : moz-landing-system : lando
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).
Depends on D66529
Differential Revision: https://phabricator.services.mozilla.com/D68041
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Converts security.data_uri.unique_opaque_origin to a static pref. This pref was initialized by the ClientManager in ClientPrefs, so this commit also removes those files. Somehow this pref was getting added in VarCache twice, so it also removes the places where the pref was added in Networking.
Differential Revision: https://phabricator.services.mozilla.com/D67185
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Converts security.data_uri.unique_opaque_origin to a static pref. This pref was initialized by the ClientManager in ClientPrefs, so this commit also removes those files. Somehow this pref was getting added in VarCache twice, so it also removes the places where the pref was added in Networking.
Differential Revision: https://phabricator.services.mozilla.com/D67185
--HG--
extra : moz-landing-system : lando
Callers should pass in UTF-8, since that's what the JS engine ends up with in the end anyway.
The various URL changes are because NS_NewURI converts incoming nsAString to
UTF-8 anyway. So we might as well do that up-front and then use the UTF-8
string for both the NS_NewURI call and the error-reporting if it fails.
Differential Revision: https://phabricator.services.mozilla.com/D65543
--HG--
extra : moz-landing-system : lando
Now that we're guaranteed to not have an existing ClientSource in the old process, we no longer need to allocate a new ClientInfo in the new process.
This lets us just create a ClientSource around the ClientInfo already on the channel (exactly as we do for same-process loads), and we no longer need to reconcile changes with the parent.
Differential Revision: https://phabricator.services.mozilla.com/D63808
--HG--
extra : moz-landing-system : lando
Rather than creating a ClientSource in the content process for the initial URL, this changes us to just create the ClientInfo in the parent, as we do for redirects.
Differential Revision: https://phabricator.services.mozilla.com/D63807
--HG--
extra : moz-landing-system : lando
This should be a no-op, but should make the following changes easier to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D63805
--HG--
extra : moz-landing-system : lando
Rather than creating a ClientSource in the content process for the initial URL, this changes us to just create the ClientInfo in the parent, as we do for redirects.
Differential Revision: https://phabricator.services.mozilla.com/D63807
--HG--
extra : moz-landing-system : lando
