OOPIF: Remove the FrameTreeNode when a RemoteFrame is detached.

content/renderer/render_frame_proxy.cc

Index: content/renderer/render_frame_proxy.cc
diff --git a/content/renderer/render_frame_proxy.cc b/content/renderer/render_frame_proxy.cc
index ae6d699ae739783c76a70f4dcb05fcd246c45949..1523fb7356ad8116068df6344f65f923313efb1b 100644
--- a/content/renderer/render_frame_proxy.cc
+++ b/content/renderer/render_frame_proxy.cc
@@ -304,9 +304,14 @@ void RenderFrameProxy::OnDidUpdateName(const std::string& name) {
 }
 
 void RenderFrameProxy::frameDetached() {
-  if (web_frame_->parent())
+  if (web_frame_->parent()) {
     web_frame_->parent()->removeChild(web_frame_);
 
+    // Let the browser process know this subframe is removed, so that it is
+    // destroyed in its current process.
+    Send(new FrameHostMsg_Detach(routing_id_));

[dcheng, 2015/04/06 23:34:18]

If there are several proxies for this frame, do the proxies then send this IPC
message back up too?

[Charlie Reis, 2015/04/07 18:45:56]

Sadly yes, but the browser process won't be listening anymore.

For example, a page with a mainframe on A and two subframes on B and C might try
to remove the B subframe.  Then:
1) A's process will send up this IPC from its RFP.
2) That causes the browser to kill the FrameTreeNode, deleting the RFH for B and
the RFPH for C.
3) C's RFPH destructor will send a DeleteProxy message to its RFP, and then it
will call RemoveRoute (causing us to drop any further IPCs).
4) The RFP will hear the DeleteProxy message, which leads to this frameDetached
call again.  However, the browser process won't recognize the route anymore and
it will be dropped.

I'm guessing this frame deletion dance could be cleaned up further, but this
should work for the time being.  Better than leaving the processes around, at
any rate.

+  }
+
   web_frame_->close();
   delete this;
 }