PlzNavigate: implement CommitNavigation on the browser side

content/browser/frame_host/render_frame_host_manager.h

Index: content/browser/frame_host/render_frame_host_manager.h
diff --git a/content/browser/frame_host/render_frame_host_manager.h b/content/browser/frame_host/render_frame_host_manager.h
index 48a5f24b6f4e79f999567b0770c82fd6565c22ae..5e6a86b9bd237cc8cdba1a0c0c6615bc9af04428 100644
--- a/content/browser/frame_host/render_frame_host_manager.h
+++ b/content/browser/frame_host/render_frame_host_manager.h
@@ -18,6 +18,7 @@
 #include "content/public/common/referrer.h"
 
 struct FrameHostMsg_BeginNavigation_Params;
+struct FrameMsg_CommitNavigation_Params;
 struct FrameMsg_Navigate_Params;
 
 namespace content {
@@ -316,8 +317,9 @@ class CONTENT_EXPORT RenderFrameHostManager : public NotificationObserver {
   // PlzNavigate: sends a RequestNavigation IPC to the renderer to ask it to
   // navigate. If no live renderer is present, then the navigation request will
   // be sent directly to the ResourceDispatcherHost.
-  bool RequestNavigation(const NavigationEntryImpl& entry,
-                         const FrameMsg_Navigate_Params& navigate_params);
+  bool RequestNavigation(
+      scoped_ptr<FrameMsg_CommitNavigation_Params> commit_navigation_params,

[(Do not use) nasko, 2014/08/28 16:39:09]

Why do we need to have commit parameters at the RequestNavigation time?

[clamy, 2014/09/02 18:25:19]

Because they depend on information stored in the NavigationEntry, and in the
discussion about the previous CL, we agreed that we should not depend on the
pending entry of the NavigationController. Which means that the only moment
where we have access to the NavigationEntry is when we are asked to navigate,
that is on RequestNavigation.

[nasko, 2014/09/03 16:30:26]

Yes, I agree that we shouldn't depend on NavigationEntry. One idea I was
discussing with Charlie is to have one structure that follows a full navigation
from the beginning to the end, carrying the common data that needs to be passed
around. Things like referrer and redirect chain can be part of it and we can
easily track it around. Each specific IPC can use that structure for the common
parts and additional params struct for the IPC specific parts. What do you
think?

[clamy, 2014/09/03 17:15:15]

I think that would work. This is essentially what the
FrameMsg_CommitNavigation_Params are doing here. Initially, I did not want to
add an additional structure (because we do have _plenty_ of structures already).
However, reading the code again, it may be more understandable than having the
FrameMsg_CommitNavigation_Params so early in the navigation.

+      const FrameMsg_Navigate_Params& navigate_params);
 
   // PlzNavigate: Used to start a navigation. OnBeginNavigation is called
   // directly by RequestNavigation when there is no live renderer. Otherwise, it
@@ -535,6 +537,10 @@ class CONTENT_EXPORT RenderFrameHostManager : public NotificationObserver {
   // it commits.
   scoped_ptr<NavigationRequest> navigation_request_;
 
+  // PlzNaigate: Holds info that should be sent to the renderer when the
+  // navigation is about to commit.
+  scoped_ptr<FrameMsg_CommitNavigation_Params> commit_navigation_params_;
+
   base::WeakPtrFactory<RenderFrameHostManager> weak_factory_;
 
   DISALLOW_COPY_AND_ASSIGN(RenderFrameHostManager);