Fix leaking of RenderFrames.

content/common/frame_messages.h

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // IPC messages for interacting with frames.
 // Multiply-included message file, hence no include guard.
 
 #include "cc/surfaces/surface_id.h"
 #include "cc/surfaces/surface_sequence.h"
 #include "content/common/content_export.h"
@@ skipping 462 matching lines @@
 // disowned.
 IPC_MESSAGE_ROUTED1(FrameMsg_UpdateOpener, int /* opener_routing_id */)
 
 // Requests that the RenderFrame send back a response after waiting for the
 // commit, activation and frame swap of the current DOM tree in blink.
 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
 // be set to the object identified by |opener_routing_id|, or to null if that
 // is MSG_ROUTING_NONE.  The new proxy should be created as a child of the
 // object identified by |parent_routing_id| or as top level if that is
 // MSG_ROUTING_NONE.
 IPC_MESSAGE_CONTROL5(FrameMsg_NewFrameProxy,
                      int /* routing_id */,
                      int /* render_view_routing_id */,
@@ skipping 708 matching lines @@
 IPC_MESSAGE_ROUTED1(FrameHostMsg_ShowPopup,
                     FrameHostMsg_ShowPopup_Params)
 IPC_MESSAGE_ROUTED0(FrameHostMsg_HidePopup)
 
 #endif
 
 // Adding a new message? Stick to the sort order above: first platform
 // independent FrameMsg, then ifdefs for platform specific FrameMsg, then
 // platform independent FrameHostMsg, then ifdefs for platform specific
 // FrameHostMsg.