RenderFrameHost on the MPArch project.
The main frame and iframe are mirrored as
RenderFrameHost in MPArch
FrameTreeNode and the document of each frame is mirrored as
FrameTreeNode has a current
RenderFrameHost, which can change over time as the frame is navigated.
Let’s look at the relationship between
RenderFrameHost of features using the MPArch structure.
RenderFrameHost, is saved in BFCache, and when the back/forward action occurs,
RenderFrameHost is restored from BFCache. The
FrameTreeNode is kept when
RenderFrameHost is saved/restored.
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.
FrameTreeNode had is replaced with
RenderFrameHost in Prerender.
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.
The GuestView and Portals are implemented with a multiple
WebContents model and considering refactoring to MPArch.
RenderFrameHost has started running unload handlers (this includes handlers for the
visibilitychange events) or when
RenderFrameHost has completed running the unload handlers,
RenderFrameHost‘s lifecycle is in the pending Deletion.
RenderFrameHost that enters BFCache, accessing
FrameTreeNode from old
RenderFrameHost that has already been swapped from the prerendered page, or accessing
FrameTreeNode in the pending deletion status all have security issues. Currently,
RenderFrameHost has direct access to
FrameTreeNode internally and exposed methods to allow access to
A meta bug 1179502 addresses this issue.
RenderFrameHostOwner is an interface for
RenderFrameHost to communicate with
FrameTreeNode owning it which can be null or can change during the lifetime of
RenderFrameHost to 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
FrameTreeNode is used, we are auditing them if we could replace
RenderFrameHostOwner after checking what lifecycle states of
RenderFrameHost we 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.