Now that the ShouldRFP member is correctly populated (we hope)
in CookieJarSettings, we can use it in our ShouldRFP methods.
There are two general scenarios:
An exempted domain frames a non-exempted domain.
The inner frame should be non-exempted.
A non-exempted domain frames an exempted domain
The inner frame should be non-exempted.
In the first scenario, CookieJarSettings.shouldRFP member
will be false (exempted.) We clearly cannot blindly rely
on the member, it would be wrong here.
In the second scenario, CookieJarSettings.shouldRFP member
will be true (non-exempted). This is the scenario we really
need CookieJarSettings for.
----
We take the opportunity to add an additional check for the
'exempted domain framed by a non-exempted domain' scenario.
This additional check takes advantage of the first party
isolation key (for FPI) or partition key (for dFPI).
Differential Revision: https://phabricator.services.mozilla.com/D150589
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
Before we took a very simplistic view to domain-based RFP
exemptions - if the loading principal said an exempted
domain, you were exempted.
This did not intelligently take into account iframes. In
particular, if a non-exempted domain framed an exempted
domain, the exempted domain's iframe would be exempted.
It probably should not. This is debatable, but at this
point in time after consultation with Tor we are going
to take the approach described in the comments in
CookieJarSettings.h
Notably this is creating a gap when it comes to nested
iframes. If an exempted domain iframes a non-exempted
domain, which in turn iframes an exempted domain - the
innermost iframe will be exempted even though its parent
is not. This is not ideal, once a document is non-
exempted, all children should be non-exempted. But this
is especially difficult to implement with the facilities
easily available to us, so we leave this corner case for
another day.
Differential Revision: https://phabricator.services.mozilla.com/D150587
Testing indicated that for a SubDocument, the loading principal
is that of the parent document, but the final channel uri is
the uri of the subdocument. In this situation, use the final
channel uri just as we do for a Document.
Differential Revision: https://phabricator.services.mozilla.com/D150586
In rare cases, we will need to see if we ShouldRFP using
only a URI and OA. (This is already the case for a
top-level load.)
Abstract this check into its own function, but at the
same time explicitly label it as dangerous and require
the developer to provide a justification why they need
to use it to hopefully prevent misuse.
Differential Revision: https://phabricator.services.mozilla.com/D150585
- Reorder ShouldRFP(char* justification) to put it first
- Add a log line about a null dochsell to be consistent
- Significantly alter the ShouldRFP(nsIPrincipal) check:
Before, it was a coarse function, if you weren't system
principal, it just checked the pref.
Now, it has been combined with the ShouldRFP(nsIPrincipal, OriginAttributes)
function, which was fine-grained. That function didn't
need to exist, because we can _get_ the OriginAttributes
_from_ the principal.
Because before we were retrieving the OA from the loadInfo
(and not the principal) we add an assert to ensure they're
the same.
We eliminate the ShouldRFP(nsIPrincipal, OriginAttributes)
function entirely and convert its one caller into just
passing the principal.
One result of all of this is that the ShouldRFP(nsIPrincipal)
check has been turned into a fine-grained check.
Differential Revision: https://phabricator.services.mozilla.com/D146945
Instead of trying to get the ScriptObjectPrincipal
of a window; use the window's Document, which will
take into account a lot more context.
Differential Revision: https://phabricator.services.mozilla.com/D150584
Cleanup our entitlement files by removing entitlements that use the default setting of false.
production.entitlements.xml and developer.entitlements.xml are used today.
The browser and plugin-container entitlement lists will be used when we enable using different entitlements for parent and child processes.
Differential Revision: https://phabricator.services.mozilla.com/D151943
The suggested solution for this bug is to disable browser.fixup.alternate.enabled
unless toggled by the user, and to add telemetry to the preference so that if we
find users rarely use the option, we can safely remove the feature in a future release.
Many tests rely on expecting URI's to be modified, so I modified them so that they
should not expect the prefix or suffix to be modified.
Differential Revision: https://phabricator.services.mozilla.com/D147795
This skips post barriers for MapObject tables when the JS Map object is in the
nursery. The change to the finalizer is required so that we don't try and
remove store buffer entries that were not created in the first place.
I don't like the way this works by casting the table pointer to a different type
with the same memory layout, but it's something we do already in that code and
it's the simplest solution to this problem.
Differential Revision: https://phabricator.services.mozilla.com/D151916
Test can be reenabled after the migration to Python 3.7+ (bug 1734402) because
the fixed Poetry version (1.2.0) has that as minimum requirement.
Differential Revision: https://phabricator.services.mozilla.com/D151913
At least in gecko, we are generating a pointermove event for each
pointer even when there was no actual change. This corresponds to the
behaviour of touch events, where the touchmove event includes all
active touch points.
Although this looks like it doesn't match the intent of the Pointer
Events spec, for an infrastructure test that's just checking if the
testdriver feature is supported, it seems better to allow the
discrepancy from the ideal behaviour rather than imply that the whole
feature is broken.
Differential Revision: https://phabricator.services.mozilla.com/D151276
For touch type pointers gecko doesn't support all the properties in pointer-events (and
it's not even very clear to me that they all make sense; how can one talk about the twist of
a finger, for example?). So split out a version of the tests that only test the properties
which are supported, so that we can regression-test the basics without failing due to missing
support at the engine layer for more complex properties.
Differential Revision: https://phabricator.services.mozilla.com/D139121
Touch is a bit different to mouse inputs because there are often
multiple pointers (i.e. fingers) acting at the same time. It turns out
that Gecko wants a single call containing all the positions etc. of
the touch pointers for each event, rather than having a single call
per pointer. So we have to group the pointer actions from one tick
together.
Differential Revision: https://phabricator.services.mozilla.com/D139120
