Pass internal content policy type to DLL and switch behavior depending on type
being loaded. This implementation immediately redirects channel back to the
content process for further handling.
Depends on D80406
Differential Revision: https://phabricator.services.mozilla.com/D80407
LoadInfo has a number of constructors intended to be used in different contexts.
Add named factory functions to make it clearer in which context the returns
LoadInfo is being used.
Depends on D80404
Differential Revision: https://phabricator.services.mozilla.com/D80405
Pass internal content policy type to DLL and switch behavior depending on type
being loaded. This implementation immediately redirects channel back to the
content process for further handling.
Differential Revision: https://phabricator.services.mozilla.com/D80407
LoadInfo has a number of constructors intended to be used in different contexts.
Add named factory functions to make it clearer in which context the returns
LoadInfo is being used.
Differential Revision: https://phabricator.services.mozilla.com/D80405
Keeping a list of ancestor principals in a LoadInfo object, that, at times,
exists in the content process, is not secure. Since ancestor principals are
only ever needed to create a list of frameAncestors, which, in turn, are only
ever accessed from the parent process, we can assemble lists of ancestor
principals and outer windowIDs whenever we are in the parent process and are
either 1) creating a LoadInfo object or 2) deserializing a LoadInfoArgs struct,
received from content process, into a LoadInfo object.
Differential Revision: https://phabricator.services.mozilla.com/D78406
DocumentLoadListener assumes loading of frames with an available
BrowsingContext. Most of the required information is obtained from the BC's
WindowGlobalParent. Extract that common functionality to support using DLL to
load content from <object>/<embed>.
Differential Revision: https://phabricator.services.mozilla.com/D78221
Currently, the worker's COEP is saved in WorkerPrivate and not be respected when loading resources in workers.
This patch adds an attribute loadingEmbedderPolicy in nsILoadInfo, which indicates the COEP header the loading must be respected.
The default value of loadingEmbedderPolicy is nsILoadInfo::EMBEDDER_POLICY_NULL.
loadingEmbedderPolicy is initialized with the COEP of the BrowsingContext used for creating LoadInfo.
And it could be set to other value when fetch in workers.
Differential Revision: https://phabricator.services.mozilla.com/D73690
We add a 'IsThirdPartyContextToTopWindow' flag in the LoadInfo. This
flag shows if the channel is considered as a third party related to the
top-level window.
This flag would be set when opening the channel in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D73199
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
--HG--
extra : moz-landing-system : lando
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
We add a flag 'HasStoragePermission' in the LoadInfo. This flag
represents whether the loading document, for docuemnt loads, or the
loading resource has the storage permission. And this flag would only
get updated in the parent process when opening the channel.
Differential Revision: https://phabricator.services.mozilla.com/D67466
--HG--
extra : moz-landing-system : lando
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
--HG--
rename : netwerk/cookie/CookieSettings.cpp => netwerk/cookie/CookieJarSettings.cpp
rename : netwerk/cookie/nsICookieSettings.idl => netwerk/cookie/nsICookieJarSettings.idl
extra : moz-landing-system : lando
We currently extract Document pointers from the old LoadInfo, and attach them to the new one, such that they aren't lost during serialization.
This moves us to setting them more directly from their original source, since the old LoadInfo is no longer reliable (and was only configured fully in the parent process).
Differential Revision: https://phabricator.services.mozilla.com/D64249
--HG--
extra : moz-landing-system : lando