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
When starting a load via the ParentProcessDocumentChannel, the event http-on-modify-request will be fired before the DocumentLoadListener has a chance to set the notificationCallback attribute.
When using a DocumentChannel, this test will not trigger the expected codepath as the DOMWindowCreated event will be fired once the channel is fully up and running; which in effect is also a fix of the original bug 1339722
Instead we use the document-on-modify-request event when the DocumentChannel is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D70011
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
We have to add "IsThirdPartyWindow" in WindowContext because we need to know if
a BrowsingContext is third-party (The browsing context may be not
in-process).
Differential Revision: https://phabricator.services.mozilla.com/D71010
This reverts a previously introduced regression. See the Bugzilla
comments of this bug.
The key consequence of this is change is that copy-pasting multiple
click-selected table rows now works again for some applications (and
shouldn't be broken for others). That's because the clipboard flavor
"text/_moz_htmlcontext" doesn't contain a superfluous "<tr>" anymore.
The fix could presumably be more elegant, but it would be hard to ensure
no other applications relying on the old behavior break.
Differential Revision: https://phabricator.services.mozilla.com/D71982
Because we would check the storage access permission inside
nsGlobalWindowInner::ExecutionReady(), so we need to set the
'HasStoragePermission' flag before we call it in
nsGlobalWindowOuter::SetNewDocument().
In addition, we check the assertion in the
ClientSource::WindowExecutionReady() back to a diagnostic assertion.
Depends on D71564
Differential Revision: https://phabricator.services.mozilla.com/D71565
That's what Chrome does basically and it does quite make sense. But in the test
case of test_meta_viewport_removing_content_attribute.html which removes a valid
content attribute, Chrome uses the removed content, which seems a bug in Chrome
I've reported before [1], and I believe we shouldn't mimic the bug.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=986674
Differential Revision: https://phabricator.services.mozilla.com/D71879
When starting a load via the ParentProcessDocumentChannel, the event http-on-modify-request will be fired before the DocumentLoadListener has a chance to set the notificationCallback attribute.
When using a DocumentChannel, this test will not trigger the expected codepath as the DOMWindowCreated event will be fired once the channel is fully up and running; which in effect is also a fix of the original bug 1339722
Instead we use the document-on-modify-request event when the DocumentChannel is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D70011
When starting a load via the ParentProcessDocumentChannel, the event http-on-modify-request will be fired before the DocumentLoadListener has a chance to set the notificationCallback attribute.
When using a DocumentChannel, this test will not trigger the expected codepath as the DOMWindowCreated event will be fired once the channel is fully up and running; which in effect is also a fix of the original bug 1339722
Instead we use the document-on-modify-request event when the DocumentChannel is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D70011
This will correctly handle the case of "display:grid" or "display:flex" being
added or removed from the Element frame right before the call to
getGridFragments or getAsFlexContainer on the Element.
Differential Revision: https://phabricator.services.mozilla.com/D71806
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
`window.content` is currently disabled only in Nightly by C preprecessor, and this patch replaces it with a new flag to allow users to manipulate.
Differential Revision: https://phabricator.services.mozilla.com/D71775
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
This is cheaper than calling Element::GetGridFragments as it does not need to
to construct an entire array of results. Most uses of GetGridFragments in the
devtools are only testing for the existence of grid fragments, and can be
changed to this cheaper method instead.
Differential Revision: https://phabricator.services.mozilla.com/D71674
This commit:
- removes sendRpcMessage, which was unused;
- removes the CPOW argument to sendAsyncMessage, broadcastAsyncMessage, and
sendSyncMessage;
- removes the aIsSync argument used internally to distinguish sendRpcMessage
and sendSyncMessage;
- removes CPOW tests;
- updates the few remaining callsites that use more than 2 arguments in
sendAsyncMessage for the removal of the cpows argument.
Differential Revision: https://phabricator.services.mozilla.com/D71514
Since we don't support downscaling animated images we'll need something like this even we were to try to request a smaller sized decode.
Differential Revision: https://phabricator.services.mozilla.com/D71523
This patch adds support for the capture and replaying of multiple frames
during normal operation of Firefox. Ctrl + Shift + 6 starts capturing
and pressing it again stops capturing. It attempts to capture the minimum
amount of data required to replay a sequence for debugging purposes.
There are several known limitations, particularly surrounding replaying
when transitioning between snapshots of the resource cache. It will
reload the entire document set, causing greater delay between frames.
Should you advance too quickly, it may also panic due to a race between
the current frame still being generated, and the new frame resetting the
resource cache state. These should be resolved with time, and the
current implementation should be workable to at least capture/debug most
animated issues with some effort.
It also adds support for loading dynamic properties which is necessary
for accurate replaying of a captured frame (sequence or individual)
which are in the middle of an animation.
Differential Revision: https://phabricator.services.mozilla.com/D59755
