For the new subframe FrameNavigationEntry based navigation logic ( issue 236848 ), the renderer process sends an IPC to the browser process when creating new child frames during a back/forward navigation, in order to look for a history item to load in the frame. This operation used to be synchronous, since the PageState in the renderer process used to have a tree of history items, rather than just one for a specific frame.
Making it asynchronous is not a problem in most cases, and it's necessary when the subframe history item needs to be loaded in a different process. However, we've had to introduce some hacks to deal with the case of about:blank, which should have loaded synchronously (allowing the parent page to immediately start scripting it). We're having to ignore attempts to redundantly navigate to about:blank, to avoid clobbering scheduled navigations ( issue 585194 's dynamic-iframe case in r406861, and now issue 638088 ) and injected content (issue 626416 in r410748).
To avoid these hacks and optimize the common case that subframe history items load in the same process as their parent frame, we should consider sending the subtree of same-process PageStates when navigating a frame back/forward. The renderer process could cache this subtree to use as the frames are created, rather than having to ask the browser process every time. (We could optionally include the unique names of all frames in the subtree, even the ones that won't load in this process, so that the fallback case can be handled by the renderer as well.)
Comment 1 by bugdroid1@chromium.org
, Sep 22 2016