Rename RenderViewGone IPC/methods to better reflect reality

content/common/view_messages.h

 // Copyright (c) 2012 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 page rendering.
 // Multiply-included message file, hence no include guard.
 
 #include "base/process.h"
 #include "base/shared_memory.h"
 #include "base/strings/string16.h"
@@ skipping 1390 matching lines @@
 // to run in a modal fashion until it is closed.
 IPC_SYNC_MESSAGE_ROUTED1_0(ViewHostMsg_RunModal,
                            int /* opener_id */)
 
 // Indicates the renderer is ready in response to a ViewMsg_New or
 // a ViewMsg_CreatingNew_ACK.
 IPC_MESSAGE_ROUTED0(ViewHostMsg_RenderViewReady)
 
 // Indicates the renderer process is gone.  This actually is sent by the
 // browser process to itself, but keeps the interface cleaner.
-IPC_MESSAGE_ROUTED2(ViewHostMsg_RenderViewGone,
+IPC_MESSAGE_ROUTED2(ViewHostMsg_RenderProcessGone,
                     int, /* this really is base::TerminationStatus */

[palmer, 2013/07/09 17:47:15]

Use that type, then? In a subsequent CL. :)

[nasko, 2013/07/09 19:12:48]

Sounds better in a separate CL.

                     int /* exit_code */)
 
 // Sent by the renderer process to request that the browser close the view.
 // This corresponds to the window.close() API, and the browser may ignore
 // this message.  Otherwise, the browser will generates a ViewMsg_Close
 // message to close the view.
 IPC_MESSAGE_ROUTED0(ViewHostMsg_Close)
 
 // Send in response to a ViewMsg_UpdateScreenRects so that the renderer can
 // throttle these messages.
@@ skipping 902 matching lines @@
 // Since the browser keeps handles to the allocated transport DIBs, this
 // message is sent to tell the browser that it may release them when the
 // renderer is finished with them.
 IPC_MESSAGE_CONTROL1(ViewHostMsg_FreeTransportDIB,
                      TransportDIB::Id /* DIB id */)
 #endif
 
 // Adding a new message? Stick to the sort order above: first platform
 // independent ViewMsg, then ifdefs for platform specific ViewMsg, then platform
 // independent ViewHostMsg, then ifdefs for platform specific ViewHostMsg.