In Document::HasStorageAccess(), we try to get the top-level document.
To check if the document is first-party to the top-level document. But,
this won't work for Fission since the top-level document could be
out-of-process.
In this patch, we use broswing context to get the top-level principal to
test if the document is thrid-party. If we cannot get the top-level
outer window, the top-level document should be cross-origin. So, we know
the answer. If the top-level document is available, we check the
principal to see if the document is first-party.
Differential Revision: https://phabricator.services.mozilla.com/D72664
- Add functions for traversing stylesheets in DocumentOrShadowRoot
- Add functions for unlinking stylesheets in DocumentOrShadowRoot
- Traverse and Unlink Document::mAdditionalSheets
Differential Revision: https://phabricator.services.mozilla.com/D72708
There are two places where we save storage permission:
1. LoadInfo hasStoragePermission attribute
2. mStorageAccessGranted in nsPIDOMWindowInner
For LoadInfo.hasStoragePermission, it is set during channel creation and
its value remains the same even when the storage permission is granted
afterward.
The updated storage permission for a window is saved in
mStorageAccessGranted, which has a different meaning for fission and
non-fission mode.
In non-fission mode, mStorageAccessGranted is saved in the top-level
window and it is an array containing all tracking subframes that
are allowed to access storage.
In fission mode, mStorageAccessGranted is set in individual tracking
windows that we have granted its storage permission. Although it works
like a boolean flag in fission, we still keep using an array to compatible
with the use case in non-fission mode.
Depends on D71984
Differential Revision: https://phabricator.services.mozilla.com/D71985
In Document::HasStorageAccess(), we try to get the top-level document.
To check if the document is first-party to the top-level document. But,
this won't work for Fission since the top-level document could be
out-of-process.
In this patch, we use broswing context to get the top-level principal to
test if the document is thrid-party. If we cannot get the top-level
outer window, the top-level document should be cross-origin. So, we know
the answer. If the top-level document is available, we check the
principal to see if the document is first-party.
Differential Revision: https://phabricator.services.mozilla.com/D72664
In Document::HasStorageAccess(), we try to get the top-level document.
To check if the document is first-party to the top-level document. But,
this won't work for Fission since the top-level document could be
out-of-process.
In this patch, we use broswing context to get the top-level principal to
test if the document is thrid-party. If we cannot get the top-level
outer window, the top-level document should be cross-origin. So, we know
the answer. If the top-level document is available, we check the
principal to see if the document is first-party.
Differential Revision: https://phabricator.services.mozilla.com/D72664
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
Follow-up parts in this bug depend on being able to read the `nsGlobalWindow`
which embeds a `nsFrameLoader` within `CreateBrowsingContext`, which is called
from the `nsFrameLoader` constructor. Unfortunately, we depend on creating the
`nsFrameLoader` and `BrowsingContext` before we have the window as part of the
fix to bug 1577711.
This patch changes `BuildNestedPrintObjects` to instead use a list of pending
clones stored on the parent `Document` object, and delays creation of the
`nsFrameLoader`, and thus the inner `BrowsingContext`, until after the document
has an owner global.
Due to the low number of automated tests for printing, I manually tested
print-previewing both the reduced test case from bug 1577711, a wikipedia
article, and 'data:text/html,<object data="data:text/html,hi">' to avoid
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D71236
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
Follow-up parts in this bug depend on being able to read the `nsGlobalWindow`
which embeds a `nsFrameLoader` within `CreateBrowsingContext`, which is called
from the `nsFrameLoader` constructor. Unfortunately, we depend on creating the
`nsFrameLoader` and `BrowsingContext` before we have the window as part of the
fix to bug 1577711.
This patch changes `BuildNestedPrintObjects` to instead use a list of pending
clones stored on the parent `Document` object, and delays creation of the
`nsFrameLoader`, and thus the inner `BrowsingContext`, until after the document
has an owner global.
Due to the low number of automated tests for printing, I manually tested
print-previewing both the reduced test case from bug 1577711, a wikipedia
article, and 'data:text/html,<object data="data:text/html,hi">' to avoid
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D71236
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
Follow-up parts in this bug depend on being able to read the `nsGlobalWindow`
which embeds a `nsFrameLoader` within `CreateBrowsingContext`, which is called
from the `nsFrameLoader` constructor. Unfortunately, we depend on creating the
`nsFrameLoader` and `BrowsingContext` before we have the window as part of the
fix to bug 1577711.
This patch changes `BuildNestedPrintObjects` to instead use a list of pending
clones stored on the parent `Document` object, and delays creation of the
`nsFrameLoader`, and thus the inner `BrowsingContext`, until after the document
has an owner global.
Due to the low number of automated tests for printing, I manually tested
print-previewing both the reduced test case from bug 1577711, a wikipedia
article, and 'data:text/html,<object data="data:text/html,hi">' to avoid
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D71236
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
Follow-up parts in this bug depend on being able to read the `nsGlobalWindow`
which embeds a `nsFrameLoader` within `CreateBrowsingContext`, which is called
from the `nsFrameLoader` constructor. Unfortunately, we depend on creating the
`nsFrameLoader` and `BrowsingContext` before we have the window as part of the
fix to bug 1577711.
This patch changes `BuildNestedPrintObjects` to instead use a list of pending
clones stored on the parent `Document` object, and delays creation of the
`nsFrameLoader`, and thus the inner `BrowsingContext`, until after the document
has an owner global.
Due to the low number of automated tests for printing, I manually tested
print-previewing both the reduced test case from bug 1577711, a wikipedia
article, and 'data:text/html,<object data="data:text/html,hi">' to avoid
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D71236
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
Follow-up parts in this bug depend on being able to read the `nsGlobalWindow`
which embeds a `nsFrameLoader` within `CreateBrowsingContext`, which is called
from the `nsFrameLoader` constructor. Unfortunately, we depend on creating the
`nsFrameLoader` and `BrowsingContext` before we have the window as part of the
fix to bug 1577711.
This patch changes `BuildNestedPrintObjects` to instead use a list of pending
clones stored on the parent `Document` object, and delays creation of the
`nsFrameLoader`, and thus the inner `BrowsingContext`, until after the document
has an owner global.
Due to the low number of automated tests for printing, I manually tested
print-previewing both the reduced test case from bug 1577711, a wikipedia
article, and 'data:text/html,<object data="data:text/html,hi">' to avoid
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D71236
Should also have no behavior change.
After the previous patch we don't have sheets associated with a document but
not owned by it, so take advantage of that.
Differential Revision: https://phabricator.services.mozilla.com/D71264
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
- Remove function `Document::RemoveStyleSheet()`
- Remove function `ShadowRoot::RemoveSheet()`
- Remove function `DocumentOrShadowRoot::RemoveSheet()`, which was used by the former two functions.
- Add function `DocumentOrShadowRoot::RemoveStyleSheet()`, now uesed in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D70927
Fullscreen stack isn't part of the spec anymore, it's changed to a
more generic version called Top Layer stack, which is being used
by both fullscreen APIs and dialog elements.
This patch refactors it to Top Layer stack so that it can be reused
for dialog element.
Top Layer stack : https://fullscreen.spec.whatwg.org/#new-stacking-layer
Differential Revision: https://phabricator.services.mozilla.com/D68478
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
