Use ChildFrameDisconnector when detaching child frames of a LocalFrame.

third_party/WebKit/Source/core/frame/RemoteFrame.cpp

Index: third_party/WebKit/Source/core/frame/RemoteFrame.cpp
diff --git a/third_party/WebKit/Source/core/frame/RemoteFrame.cpp b/third_party/WebKit/Source/core/frame/RemoteFrame.cpp
index f7eb7a08a368f0cd66401f2ba38e6a0867a15107..0c3c253a18989c5009bb8b7096b5c7f0d5847f40 100644
--- a/third_party/WebKit/Source/core/frame/RemoteFrame.cpp
+++ b/third_party/WebKit/Source/core/frame/RemoteFrame.cpp
@@ -196,4 +196,15 @@ void RemoteFrame::advanceFocus(WebFocusType type, LocalFrame* source)
     client()->advanceFocus(type, source);
 }
 
+void RemoteFrame::detachChildren()
+{
+    using FrameVector = HeapVector<Member<Frame>>;
+    FrameVector childrenToDetach;
+    childrenToDetach.reserveCapacity(tree().childCount());
+    for (Frame* child = tree().firstChild(); child; child = child->tree().nextSibling())

[esprehn, 2016/07/11 19:39:30]

why do we need to keep this code path for remote frames? I think in most pages
the frame tree is interleaved Remote and Local frames so you're likely to end up
down this code path really often.

[dcheng, 2016/07/12 01:14:41]

ChildFrameDisconnector is based on DOM nodes, which remote frames don't have, so
we need an alternate path for remote frames. It's a bit unfortunate, but it's
not much different from before: previously, both versions delegate to a
non-virtual Frame::detachChildren: now they just happen to delegate to different
implementations of detachChildren.

+        childrenToDetach.append(child);
+    for (const auto& child : childrenToDetach)
+        child->detach(FrameDetachType::Remove);

[esprehn, 2016/07/13 02:35:45]

this doesn't use a SubframeLoadingDisabler, so the script in here can load more
frames which then get missed by the above logic in the RemoteFrame case. That's
probably a security bug that already exists.

+}
+
 } // namespace blink