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
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
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
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
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 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
These were added for the sake of app browsers, and all of the code which
actually needed them has since been removed.
Differential Revision: https://phabricator.services.mozilla.com/D70741
These were added for the sake of app browsers, and all of the code which
actually needed them has since been removed.
Differential Revision: https://phabricator.services.mozilla.com/D70741
These were added for the sake of app browsers, and all of the code which
actually needed them has since been removed.
Differential Revision: https://phabricator.services.mozilla.com/D70741
This patch adds a `openWindowInfo` XPCOM attribute to the `nsIBrowser` interface
supported by the browser custom element. This attribute is then read by
`XULFrameElement`, and passed to `nsFrameLoader` to ensure the relevant flags
are used for newly opened windows.
This patch does not add support for passing openWindowInfo into mozbrowser
elements.
Differential Revision: https://phabricator.services.mozilla.com/D67052
--HG--
extra : moz-landing-system : lando
This also moves nsDocShell's implementation of nsILoadContext to be based on its
BrowsingContext.
This patch does not, by itself, fix all places which try to mutate
`nsILoadContext`. Those are fixed by the other parts of this patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D67045
--HG--
extra : moz-landing-system : lando
This is necessary to avoid the use of setOriginAttributesBeforeLoading, which is
being removed in this patch set.
Differential Revision: https://phabricator.services.mozilla.com/D67042
--HG--
extra : moz-landing-system : lando
This patch adds a `openWindowInfo` XPCOM attribute to the `nsIBrowser` interface
supported by the browser custom element. This attribute is then read by
`XULFrameElement`, and passed to `nsFrameLoader` to ensure the relevant flags
are used for newly opened windows.
This patch does not add support for passing openWindowInfo into mozbrowser
elements.
Differential Revision: https://phabricator.services.mozilla.com/D67052
--HG--
extra : moz-landing-system : lando
This also moves nsDocShell's implementation of nsILoadContext to be based on its
BrowsingContext.
This patch does not, by itself, fix all places which try to mutate
`nsILoadContext`. Those are fixed by the other parts of this patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D67045
--HG--
extra : moz-landing-system : lando
This is necessary to avoid the use of setOriginAttributesBeforeLoading, which is
being removed in this patch set.
Differential Revision: https://phabricator.services.mozilla.com/D67042
--HG--
extra : moz-landing-system : lando
The new name should make it more clear that this should not be the default way
to look up the BrowsingContext instance from a nsFrameLoader, as it does not
ensure that the BrowsingContext has been fully initialized and attached to the
tree.
Differential Revision: https://phabricator.services.mozilla.com/D62959
--HG--
extra : moz-landing-system : lando
The BrowsingContext is guaranteed to be being kept alive by
`nsFrameLoader::mBrowsingContext` and by the nsDocShell or RemoteBrowser object.
This improves the ergonomics of this helper method, which may help avoid misuse
of `mBrowsingContext`.
Differential Revision: https://phabricator.services.mozilla.com/D62957
--HG--
extra : moz-landing-system : lando
CLOSED TREE
Backed out changeset d6fd08e3fccf (bug 1615480)
Backed out changeset ad31eae54af2 (bug 1615480)
Backed out changeset 70aff2593d98 (bug 1615480)
The new name should make it more clear that this should not be the default way
to look up the BrowsingContext instance from a nsFrameLoader, as it does not
ensure that the BrowsingContext has been fully initialized and attached to the
tree.
Differential Revision: https://phabricator.services.mozilla.com/D62959
--HG--
extra : moz-landing-system : lando
The BrowsingContext is guaranteed to be being kept alive by
`nsFrameLoader::mBrowsingContext` and by the nsDocShell or RemoteBrowser object.
This improves the ergonomics of this helper method, which may help avoid misuse
of `mBrowsingContext`.
Differential Revision: https://phabricator.services.mozilla.com/D62957
--HG--
extra : moz-landing-system : lando
There are all sorts of lifecycle issues which arise from making DocShell
responsible for discarding BrowsingContexts. In this particular bug, we tend
to run into them in cases where we create a BrowsingContext for a FrameLoader,
and then never create a DocShell for it, leading to it never being destroyed.
But there are myriad other issues as well.
This patch moves the responsibility for BrowsingContext lifecycle management
to the FrameLoader/FrameLoaderOwner, rather than the DocShell, which makes
things more consistent, and more closely aligns with spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D59008
--HG--
extra : moz-landing-system : lando
We go to some lengths to defer FrameLoader initialization to the end of
document updates. However, it is still possible for initialization to happen
earlier as a side-effect of other operations (such as
`nsFrameLoader::GetBrowsingContext()`) if they're called before initialization
has already happened. Since this is such an easy mistake to make, we should
assert that it doesn't happen so that we find out about it sooner rather than
later.
Differential Revision: https://phabricator.services.mozilla.com/D55877
--HG--
extra : moz-landing-system : lando
This doesn't block the STATE_START notification from the new process, as we currently have a second start notification (when DocumentChannel redirects to the real channel), so this is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D56818
--HG--
extra : moz-landing-system : lando
This is necessary as the nsFrameLoader may have been swapped, due to a process
switch, before the teardown of the old nsDocShell is complete. In this case, the
nsDocShell is still present on the BrowsingContext despite a nsFrameLoader for a
remote frame having been set up.
This will also be important for future changes such as cross-process bfcache. It
may be possible to change the calls to `nsFrameLoader::GetDocShell()` back to
`mDocShell` accesses in the future.
Differential Revision: https://phabricator.services.mozilla.com/D49648
--HG--
extra : moz-landing-system : lando
