1574261 - Make nsDocShell::MaybeHandleSubFrameHistory work with session history in parent

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P2)

Description

[Kannan Vijayan [:djvj]]

https://searchfox.org/mozilla-central/source/docshell/base/nsDocShell.cpp#782

In this function, the same-type parent of the current document is obtained. If the parent is null or the same as this, then the this docshell is treated as the root.

This logic is erroneous in a post-fission semantics. The parent may be null if the parent document is out-of-process. To handle this, the logic around retrieving a parent should be changed to use the BrowsingContext to check for a parent.

Furthermore, the function goes on to retrieve the nsDocShell associated with the parent document, and perform various operations on it. The main job of the function is to adjust the session-history state of the child based on the state of the parent document.

This logic will need to be changed to use IPC to retrieve this information from a remote process (if needed). For performance reasons, it is probably a good idea to detect the situation where the parent is in process, and use the existing logic for that.

Comment 1

[Chris Peterson [:cpeterson]]

Kannan says replacing nsIDocShellTreeItem calls should block enabling Fission in Nightly (M6).

Comment 2

[Chris Peterson [:cpeterson]]

Auditing whether this use of nsIDocShellTreeItem breaks when Fission is enabled blocks Fission Nightly.

Comment 3

[Neha Kochar [:neha]]

Discussed in history meeting and we need to audit the usage and then decide whether or not it will block nightly.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Bug 1574261 - Make nsDocShell::MaybeHandleSubFrameHistory work with session history in parent, r=peterv

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 mLoadingActiveEntry. mLoadingEntry + mLoadingActiveEntry 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.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/db7ab542d0ec
Make nsDocShell::MaybeHandleSubFrameHistory work with session history in parent, r=peterv

Comment 6

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/db7ab542d0ec