This is more consistent than an assertion and it should be safe, considering that the field
should be unused on child entries anyway, so we might as well return the value from the root.
Differential Revision: https://phabricator.services.mozilla.com/D95300
document.open replaces the session history entry with a new one, the url of
which needs to point to the entry document. nsDocShell::UpdateActiveEntry wasn't
resetting the url and the originalURL in the replace case. This patch always
creates a new SessionHistoryInfo so we share more code between replace and
non-replace, to avoid missing some fields.
Differential Revision: https://phabricator.services.mozilla.com/D91273
This has couple of different pieces and one may want to focus on each of those separately when
reviewing. The first two as small changes.
- Moving mDynamicallyCreated from nsDocShell to be a sync'ed field on BrowsingContext.
CanonicalBrowsingContext::CreateLoadingSessionHistoryEntryForLoad sets that on a newly created entry.
- Adding mActiveEntryIsLoadingFromSessionHistory. mLoadingEntry + mActiveEntryIsLoadingFromSessionHistory has roughly
the same lifetime as mLSHE. mLoadingActiveEntry is needed so that child docshell can know whether its parent is loading from session history.
- The main part is in MaybeHandleSubframeHistory which checks if the parent docshell is loading from session history,
and if so, asks for a LoadingSessionHistoryInfo. In the case of docshell living in a child process that operation is asynchronous,
so when the data is back from the parent process, LoadURI is called again with the possibly updated data.
One could possibly split the code to smaller methods and then deal with aContinueHandlingSubframeHistory only in LoadURI,
but MaybeHandleSubframeHistory does have some early returns which would make that approach possibly hard to follow.
Differential Revision: https://phabricator.services.mozilla.com/D89685
The entries in the parent process stores some data in a shared state for some of
the entries that share a document. We also need to store some of this data in
the info objects in the child process, but it doesn't make sense to have it be
shared: the data shouldn't be mutated in the child process, and we probably only
have one of the info objects anyway. This adds a structure that holds the shared
data for an info object in the child process, but without actually sharing it.
As we use info objects in both parent and child, we hold a void pointer that's a
strong reference to a shared state in the parent process, and an owning pointer
to the pseudo-shared state in the child process.
Differential Revision: https://phabricator.services.mozilla.com/D87038
Checking for an nsISHEntry doesn't work anymore with session history in the
parent. For that we can check that the loading session history info's
mIsLoadFromSessionHistory is true. If there is no loading session history info
we can fall back to the old way of checking for a non-null nsISHEntry (which
will only ever be true if session history in the parent is turned off).
Differential Revision: https://phabricator.services.mozilla.com/D87037
SessionHistoryEntry::MaybeSynchronizeSharedStateToInfo call is a tad controversial, but
something like that is needed for the cases when the actual value lives in the SHEntrySharedParentState.
Differential Revision: https://phabricator.services.mozilla.com/D86640
SessionHistoryEntry::MaybeSynchronizeSharedStateToInfo call is a tad controversial, but
something like that is needed for the cases when the actual value lives in the SHEntrySharedParentState.
Differential Revision: https://phabricator.services.mozilla.com/D86640
