commit 4bc10eeb30a7dd8477fd1e37eecce8279e7bd76c
author Dominic Farolino <dom@chromium.org> Tue Aug 31 00:37:36 2021
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Aug 31 00:37:36 2021
tree bbaf9f259f5eea4a3ed15ae60c97455c1bf359bd
parent 68ee28bd80ed3bb6f4693d8e5529a7dab94ee4ef

Fenced Frames: content::FencedFrame owns a FrameTree

This CL follows-up on the work in https://crrev.com/c/2987019.

Before this CL, the content::FencedFrame object was practically a
shell. This CL begins to fill out content::FencedFrame by making the
following changes:

 - content::FencedFrame owns an "inner" MPArch FrameTree. We introduce
   a new FrameTree::Type::kFencedFrame type of FrameTree, and give
   content::FencedFrame a new `frame_tree_` member that is initialized
   in its constructor
 - Introduce
   content::FencedFrame::CreateProxyAndAttachToOuterFrameTree() which
   actually creates a(n):
     - Outer delegate child FrameTreeNode which is a child of the
       RenderFrameHostImpl that owns the content::FencedFrame object
     - RenderFrameProxyHost whose renderer-side RenderFrameProxy is
       used by Blink in the outer frame tree to remotely reference the
       inner FrameTree's main frame. This is required in the
       current architecture in order to get CrossProcessFrameConnector
       to work, though we are considering divorcing these two concepts
       in the future
 - Filling out content::FencedFrame::Navigate() to actually navigate the
   inner FrameTree via Navigator::NavigateFromFrameProxy()
 - Adding RenderFrameHost traversal tests that exercise the inner/outer
   delegate mechanisms ensuring they work for MPArch Fenced Frames
   (excluding nested fenced frames which do not work yet)
 - Adding a basic navigation test ensuring that a fenced frame's
   RenderFrameHostImpl can indeed navigate successfully

Additionally, this CL does the following:
 - WebContentsObserverConsistencyChecker: We tighten the following
   conditions in the following ways:
     - FrameTree::AddFrame used to not call RenderFrameCreated() on the
       newly-created FTN's RFHI for portals, since it was just a dummy
       FTN and would never have a real RenderFrame. We now do the same
       for MPArch fenced frames (not ShadowDOM ones) from having
       RenderFrameCreated() for the same reason
     - WebContentObserverConsistencyChecker (a test-only WCO
       implementation) implements RenderFrameHostChanged() where it
       verifies that RenderFrameCreated() is called for each newly-added
       child frame, except for portals (due to logic that mirrors
       FrameTree::AddFrame()). We modify this condition to also exclude
       the dummy child FTN's RFHIs for *fenced frames* from this check,
       to mirror our changes to FrameTree::AddFrame().
 - We change IsFencedFrame() => IsFencedFrameRoot() on FrameTreeNode,
   RenderFrameHost, and RenderFrameHostImpl
     - This is consistent with the email sent out on navigation-dev@
       that summarizes the various ways to determine if you're dealing
       with a renderer-host object associated with a fenced frame [1]

-- Lifetime --

This CL also implements the following regarding the fenced frame's
lifetime:

 - Introduce RenderFrameHostImpl::DestroyFencedFrame(FencedFrame*).
   This is a bit complicated, and the flow around this looks like so:
     1.) Something (e.g., a renderer crash) kills the outer delegate
         child FrameTreeNode in the outer FrameTree, which represents
         the inner fenced frame FrameTree
     2.) FencedFrame::OnFrameTreeNodeDestroyed() is invoked, calling...
     3.) RenderFrameHostImpl::DestroyFencedFrame(this), which calls...
     4.) FencedFrame::dtor() is invoked
   While this is complicated, we wanted to mirror the portals flow for
   now, and simplify both at once in a subsequent CL. In a subsequent
   CL, we're aiming to have RFHI explicitly destroy the portals and
   fenced frames rooted at it

[1]: https://groups.google.com/a/chromium.org/g/navigation-dev/c/duZ1Zcs2RLg

Bug: 1123606
Change-Id: Ifad64f808aa078f87dfffcaae1869d73919287d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3057656
Commit-Queue: Dominic Farolino <dom@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Shivani Sharma <shivanisha@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Christoph Schwering <schwering@google.com>
Cr-Commit-Position: refs/heads/main@{#916618}