Allow showing pending URL for new tab navigations, but only if safe.

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/string16.h"
@@ skipping 2139 matching lines @@
 IPC_MESSAGE_ROUTED3(ViewHostMsg_LockMouse,
                     bool /* user_gesture */,
                     bool /* last_unlocked_by_target */,
                     bool /* privileged */)
 
 // Requests to unlock the mouse. A ViewMsg_MouseLockLost message will be sent
 // whenever the mouse is unlocked (which may or may not be caused by
 // ViewHostMsg_UnlockMouse).
 IPC_MESSAGE_ROUTED0(ViewHostMsg_UnlockMouse)
 
+// Notifies that the initial empty document of a view has been accessed.
+// After this, it is no longer safe to show a pending navigation's URL without
+// making a URL spoof possible.
+IPC_MESSAGE_ROUTED0(ViewHostMsg_DidAccessInitialDocument)
+
 // Following message is used to communicate the values received by the
 // callback binding the JS to Cpp.
 // An instance of browser that has an automation host listening to it can
 // have a javascript send a native value (string, number, boolean) to the
 // listener in Cpp. (DomAutomationController)
 IPC_MESSAGE_ROUTED2(ViewHostMsg_DomOperationResponse,
                     std::string  /* json_string */,
                     int  /* automation_id */)
 
 // Sent to the browser when the renderer detects it is blocked on a pepper
@@ skipping 144 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.