WalkHistoryEntries function gets called by nsSHistory::CloneAndReplaceChild
and nsSHistory::SetChildHistoryEntry recursively, so those have to be moved
into the parent process. This eliminates many sync IPC calls.
To facilitate transition to a new session history design,
we are mirroring mOSHE and mLSHE SH entries from docshell to browsing context.
Whenever we update those entries in docshell, we will also update those in BC,
and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D56201
Add a new label to collect the number of BFCached documents that are not
the only top level documents in their BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D65790
Now that we're guaranteed to not have an existing ClientSource in the old process, we no longer need to allocate a new ClientInfo in the new process.
This lets us just create a ClientSource around the ClientInfo already on the channel (exactly as we do for same-process loads), and we no longer need to reconcile changes with the parent.
Differential Revision: https://phabricator.services.mozilla.com/D63808
Rather than creating a ClientSource in the content process for the initial URL, this changes us to just create the ClientInfo in the parent, as we do for redirects.
Differential Revision: https://phabricator.services.mozilla.com/D63807
Rather than creating a ClientSource in the content process for the initial URL, this changes us to just create the ClientInfo in the parent, as we do for redirects.
Differential Revision: https://phabricator.services.mozilla.com/D63807
This covers most cycle collected objects which support weak references, but
not the ones which inherit from a cycle collected class and don't do any cycle
collection on their own.
Differential Revision: https://phabricator.services.mozilla.com/D63962
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
Otherwise we're using state from the pre-open document for whatever content is
being written, which is not likely to be right.
Differential Revision: https://phabricator.services.mozilla.com/D61865
Otherwise we're using state from the pre-open document for whatever content is
being written, which is not likely to be right.
Differential Revision: https://phabricator.services.mozilla.com/D61865
In bug 1579049, response code 403 and 501 were changed to map to `NS_ERROR_PROXY_FORBIDDEN` and `NS_ERROR_PROXY_NOT_IMPLEMENTED`. This caused a regression, since 403 and 501 were mapping to `NS_ERROR_PROXY_CONNECTION_REFUSED` before. This patch fixes the regression by adding `NS_ERROR_PROXY_FORBIDDEN` and `NS_ERROR_PROXY_NOT_IMPLEMENTED` to nsDocShell.
Differential Revision: https://phabricator.services.mozilla.com/D61682
The intent of ConfigureChannel was to be code that needed to be applied to both the DocumentChannelChild in the content process, and the real channel in the parent.
It looks like everything in there is either QI'ing to a sub-type of channel (which won't apply to DocumentChannelChild), or is mutating the loadinfo/loadflags (which only need to be done once).
Differential Revision: https://phabricator.services.mozilla.com/D59264
