Fix leaking of RenderFrames.

content/common/frame_messages.h

Index: content/common/frame_messages.h
diff --git a/content/common/frame_messages.h b/content/common/frame_messages.h
index 0e0287497e6b1a3dd437e58dd355fda0ea43c865..21f23dea7aca1ad2de14c18560ce30f7a7c58fc9 100644
--- a/content/common/frame_messages.h
+++ b/content/common/frame_messages.h
@@ -480,6 +480,10 @@ IPC_MESSAGE_ROUTED1(FrameMsg_VisualStateRequest, uint64 /* id */)
 // Instructs the renderer to create a new RenderFrame object.
 IPC_MESSAGE_CONTROL1(FrameMsg_NewFrame, FrameMsg_NewFrame_Params /* params */)
 
+// Instructs the renderer to delete the RenderFrame object identified by

[Charlie Reis, 2015/10/29 17:28:58]

Maybe we should distinguish this from how RenderFrames normally get deleted?

And now that I mention it, I can't find a detach message for that.  If a parent
frame sends a FrameHostMsg_Detach to the browser process, how do we delete the
RenderFrame in the child process?  Do we?  :)

[dcheng, 2015/10/29 18:50:52]

Ah... this is going to be fun. We're going to add some logic too, so that
additional FrameHostMsg_Detach messages from the mirrored frames don't also
trigger FrameMsg_DeleteFrame to be sent.

Also, maybe just call this FrameMsg_Detach, since that it seems likely we'll end
up reusing this for that?

[nasko, 2015/10/29 19:09:45]

Unfortunately, I think you are right : (.

[nasko, 2015/10/29 19:09:45]

Yes, indeed.
 
Done.

+// |routing_id|.
+IPC_MESSAGE_CONTROL1(FrameMsg_DeleteFrame, int /* routing_id */)
+
 // Instructs the renderer to create a new RenderFrameProxy object with
 // |routing_id|.  |render_view_routing_id| identifies the
 // RenderView to be associated with this proxy.  The new proxy's opener should