RenderFrameHoston the MPArch project.
The main frame and iframe are mirrored as
RenderFrameHost in MPArch
FrameTreeNodeand the document of each frame is mirrored as
FrameTreeNodehas a current
RenderFrameHost, which can change over time as the frame is navigated. Let’s look at the relationship between
RenderFrameHostof features using the MPArch structure.
RenderFrameHost, is saved in BFCache, and when the back/forward action occurs,
RenderFrameHostis restored from BFCache. The
FrameTreeNodeis kept when
Prerender2 is a feature to pre-render the next page for faster navigation. In prerender, a document will be invisible to the user and isn’t allowed to show any UI changes, but the page is allowed to load and run in the background.
Navigation changes to support multiple pages in WebContentsWhen the prerendered page is activated, the current
FrameTreeNodehad is replaced with
The fenced frame enforces a boundary between the embedding page and the cross-site embedded document such that user data visible to the two sites is not able to be joined together.
FrameTree, and the fenced frame can be accessed through a delegate.
GuestView & Portals
Chromium implements a tag with a GuestVIew which is the templated base class for out-of-process frames in the chrome layer.
For more detail, please refer to Julie’s blog.
Portals allow the embedding of a page inside another page, which can later be activated and replace the main page.
Navigation changes to support multiple pages in WebContents
The GuestView and Portals are implemented with a multiple
WebContentsmodel and considering refactoring to MPArch.
RenderFrameHosthas started running unload handlers (this includes handlers for the
visibilitychangeevents) or when
RenderFrameHosthas completed running the unload handlers,
RenderFrameHost‘s lifecycle is in the pending Deletion.
RenderFrameHostthat enters BFCache, accessing
RenderFrameHostthat has already been swapped from the prerendered page, or accessing
FrameTreeNodein the pending deletion status all have security issues. Currently,
RenderFrameHosthas direct access to
FrameTreeNodeinternally and exposed methods to allow access to
A meta bug 1179502 addresses this issue.
RenderFrameHostOwneris an interface for
RenderFrameHostto communicate with
FrameTreeNodeowning it which can be null or can change during the lifetime of
RenderFrameHostto prevent accidental violation of implicit “associated FrameTreeNode stays the same” assumptions.
// - Owning FrameTreeNode for main RenderFrameHosts in kActive, kPrerender, // kSpeculative or kPendingCommit lifecycle states. // - Null for main RenderFrameHosts in kPendingDeletion lifecycle state. // - Null for main RenderFrameHosts stored in BFCache. // - Owning FrameTreeNode for subframes (which stays the same for the entire // lifetime of a subframe RenderFrameHostImpl).
At all places where
FrameTreeNodeis used, we are auditing them if we could replace
RenderFrameHostOwnerafter checking what lifecycle states of
RenderFrameHostwe can have. However, there are still some places that are not available to use
RenderFrameHostOwner(e.g. unload handler). We are still investigating how to deal with these cases. It would be necessary to refactor
for RenderFrameHost::frame_tree_node(), which is widely used inside and outside
RenderFrameHost, and that work is ongoing.