CookieJarSettings frequently gets populated in a place
where we have ready access to the Document/Channel it
is being constructed for. This lets us populate the boolean
and pass it into CookieJarSetting's constructor easily.
When it is created for LoadInfo, we need to plumb the URI
through by adding it to LoadInfo::CreateForDocument.
Differential Revision: https://phabricator.services.mozilla.com/D150588
In order to know if the mIsThirdPartyContextToTopWindow was set in the
loadInfo of the channel, we use maybe to hold the value. So, we can know
if it was set before.
This patch also addes two methods in LoadInfo to clear and know if the
value is set.
Differential Revision: https://phabricator.services.mozilla.com/D146491
If we enable pref browser.tabs.documentchannel.parent-controlled and remove the
requirement for needing SHIP for parent-initiated loads, test
NavigationDelegateTest#redirectIntentLoad times out. It times out because when
redirecting in Document Channel, we were using the URI of the redirect that
failed.
Differential Revision: https://phabricator.services.mozilla.com/D132093
To differentiate the storage permission is granted by either the
permission or the allowList, we need to change the hasStoragePermission
to an enum to represent the storage permission state.
This patch also changes the name of the attribute to make it reasonable
with respect to this change.
Differential Revision: https://phabricator.services.mozilla.com/D126276
This change stores a generated nsID directly on the LoadInfo, rather
than the full SandboxedLoadingPrincipal. This allows for the sandboxed
principal to be constructed from GetChannelResultPrincipal using the
unsandboxed result principal as a precursor, rather than the loading
principal.
The nsID is reset by HttpChannelBase whenever a non-internal redirect
occurs to reduce the chance of multiple null result principals during a
redirect with the same nsID, but different precursors.
Depends on D119692
Differential Revision: https://phabricator.services.mozilla.com/D119693
This patch adds a UnstrippedURI into the LoadInfo. This attribute
represents the channel's URI has been stripped if this attributes is not
a nullptr.
Having this attribute allows us to be able to revert the query stripping
in the case where the loading channel is in the content blocking allow
list in the parent process.
In addition, this patch removes the main thread assertion in URIUtils
given that we've made the URL construction thread-safe. This will allow
us to be able to use nsIURI directly in ParentLoadInfoForwarderArgs.
Differential Revision: https://phabricator.services.mozilla.com/D116108
This patch adds a flag 'needForCheckingAntiTrackingHeuristic' in
loadInfo. This flag will be used for deciding if we need to check the
AntiTracking heuristic after the channel has been classified.
Differential Revision: https://phabricator.services.mozilla.com/D107047
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
