Cleanup around LocalFrame initialization

third_party/WebKit/Source/web/WebRemoteFrameImpl.cpp

Index: third_party/WebKit/Source/web/WebRemoteFrameImpl.cpp
diff --git a/third_party/WebKit/Source/web/WebRemoteFrameImpl.cpp b/third_party/WebKit/Source/web/WebRemoteFrameImpl.cpp
index c9c5d51561a8f472835e2e2d52592a03e9dd0bbf..7f8f48f6f0857952aa185abb169ff8cc9b256929 100644
--- a/third_party/WebKit/Source/web/WebRemoteFrameImpl.cpp
+++ b/third_party/WebKit/Source/web/WebRemoteFrameImpl.cpp
@@ -332,15 +332,7 @@ WebLocalFrame* WebRemoteFrameImpl::CreateLocalChild(
   RemoteFrameOwner* owner =
       RemoteFrameOwner::Create(static_cast<SandboxFlags>(sandbox_flags),
                                container_policy, frame_owner_properties);
-  // FIXME: currently this calls LocalFrame::init() on the created LocalFrame,

[Nate Chapin, 2017/05/10 16:33:20]

I don't think this comment was correct, given that initial empty documents are
*supposed* to be invisible to content/ (unless they get scripted and
DidAccessInitialDocument gets called). Certainly, navigation notifications
should be suppressed.

-  // which may result in the browser observing two navigations to about:blank
-  // (one from the initial frame creation, and one from swapping it into the
-  // remote process).  FrameLoader might need a special initialization function
-  // for this case to avoid that duplicate navigation.
   child->InitializeCoreFrame(*GetFrame()->GetPage(), owner, name);
-  // Partially related with the above FIXME--the init() call may trigger JS
-  // dispatch. However,

[Nate Chapin, 2017/05/10 16:33:20]

This comment is now obsolete.

[dcheng, 2017/05/11 21:36:25]

Should we update the comment in LocalFrame::Init() as well?

[Nate Chapin, 2017/05/12 19:52:29]

Dropped it, it doesn't look like there's any substance besides the claim that
FrameLoader::Init() can detach the world.

-  // if the parent is remote, it should never be detached synchronously...
   DCHECK(child->GetFrame());
   return child;
 }