This is a huge patch, but it is only really refactoring of RFPTarget enum. We used to use RFPTarget as a bitset and now we ran out of bits, so now we need a workaround.
Differential Revision: https://phabricator.services.mozilla.com/D233182
This is a huge patch, but it is only really refactoring of RFPTarget enum. We used to use RFPTarget as a bitset and now we ran out of bits, so now we need a workaround.
Differential Revision: https://phabricator.services.mozilla.com/D233182
The principal of a document might be changed during loading in certain
situation, e.g. a sandboxed document. In this case, we need to recompute
the partitionKey of the document to reflect the change on the principal.
Differential Revision: https://phabricator.services.mozilla.com/D230819
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Depends on D223380
Differential Revision: https://phabricator.services.mozilla.com/D223936
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Depends on D223380
Differential Revision: https://phabricator.services.mozilla.com/D223936
The principal of a document might be changed during loading in certain
situation, e.g. a sandboxed document. In this case, we need to recompute
the partitionKey of the document to reflect the change on the principal.
Differential Revision: https://phabricator.services.mozilla.com/D230819
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Differential Revision: https://phabricator.services.mozilla.com/D223936
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Differential Revision: https://phabricator.services.mozilla.com/D223936
This handles a race condition so if the user copies new data to the clipboard
while Content Analysis is ongoing, the original data will be used in the
paste action.
Differential Revision: https://phabricator.services.mozilla.com/D228719
This handles a race condition so if the user copies new data to the clipboard
while Content Analysis is ongoing, the original data will be used in the
paste action.
Differential Revision: https://phabricator.services.mozilla.com/D228719
The raw declaration block might change for a given rule. We need to keep
track of it properly for devtools in order to not lose track of rules.
Could I convince someone from DevTools to write a test for this? :)
Otherwise please point me to the right test to extend / change, and I
can.
Differential Revision: https://phabricator.services.mozilla.com/D230439
This introduces a boolean on nsCSPPolicy / nsIContentSecurityPolicy /
Document that is initially false and only set to true after a
REQUIRE_TRUSTED_TYPES_FOR_DIRECTIVE directive is associated to the
object. This provides fast check and early return when such a directive
is absent:
- TrustedTypeUtils's GetTrustedTypesCompliantString(), currently used by
Element::SetInnertHTML() and Element::InsertAdjacentHTML().
- nsCSPPolicy::AreTrustedTypesForSinkGroupRequired() currently used by
ShouldSinkTypeMismatchViolationBeBlockedByCSP() and
DoesSinkTypeRequireTrustedTypes().
This also makes nsCSPPolicy::hasDirective() fast for
nsIContentSecurityPolicy::REQUIRE_TRUSTED_TYPES_FOR_DIRECTIVE.
Differential Revision: https://phabricator.services.mozilla.com/D226882
Extend the pageload event to store features used on the root document for better signal-to-noise detection in performance experiments.
This patch uses a bit to record documents in which fetchpriority is used on images.
Data-classification-low: Category 1 “Technical data”
Differential Revision: https://phabricator.services.mozilla.com/D222991
Calling setViewport on a background tab would wait forever without this
tweak after D221995, because we won't resize it until it becomes active.
Some tests like the ones mentioned in comment 12 call newPage() multiple
times at once, and newPage() calls setViewport() if there is a default
viewport set, which triggered this bug.
Make this work by reusing the AppWindow logic for sizing popup windows,
with a tweak so that we also resize background tabs.
Differential Revision: https://phabricator.services.mozilla.com/D222227
What goes on here is that there's a couple of unfortunate style change
sequences which end up making us not do the EffectsInfo dance correctly.
Twitter uses (maybe didn't use to, which would explain the regression) a
visibility: hidden, out-of-flow iframe for a bit (which we correctly
throttle). But then they switch to an in-flow, visible, zero-height
iframe. That we should _not_ throttle. However, we end up not getting to
the display list code at all, because nsBlockFrame decides that we don't
need to descend into an empty line[1].
It seems less error prone to re-use the IntersectionObserver timing and
computation to determine whether the iframe is visible. That completely
matches in-process iframes, too.
Removing the empty frame border and putting them on an empty line in
dom/base/test/test_bug1639328.html is enough to reproduce the issue
without this patch.
[1]: https://searchfox.org/mozilla-central/rev/fe2743c6c5c708061c7f6504b26958fcc815bb4a/layout/generic/nsBlockFrame.cpp#7569-7579
Differential Revision: https://phabricator.services.mozilla.com/D207479
What goes on here is that there's a couple of unfortunate style change
sequences which end up making us not do the EffectsInfo dance correctly.
Twitter uses (maybe didn't use to, which would explain the regression) a
visibility: hidden, out-of-flow iframe for a bit (which we correctly
throttle). But then they switch to an in-flow, visible, zero-height
iframe. That we should _not_ throttle. However, we end up not getting to
the display list code at all, because nsBlockFrame decides that we don't
need to descend into an empty line[1].
It seems less error prone to re-use the IntersectionObserver timing and
computation to determine whether the iframe is visible. That completely
matches in-process iframes, too.
Removing the empty frame border and putting them on an empty line in
dom/base/test/test_bug1639328.html is enough to reproduce the issue
without this patch.
[1]: https://searchfox.org/mozilla-central/rev/fe2743c6c5c708061c7f6504b26958fcc815bb4a/layout/generic/nsBlockFrame.cpp#7569-7579
Differential Revision: https://phabricator.services.mozilla.com/D207479
