PlzNavigate: Move the navigation logic to NavigatorImpl

content/browser/frame_host/render_frame_host_impl.cc

Index: content/browser/frame_host/render_frame_host_impl.cc
diff --git a/content/browser/frame_host/render_frame_host_impl.cc b/content/browser/frame_host/render_frame_host_impl.cc
index 28b7ff1f1dc09484598af3a37f515282e57a520b..74c2834fe94b45f2bb7e0b34c5712bd21223ca87 100644
--- a/content/browser/frame_host/render_frame_host_impl.cc
+++ b/content/browser/frame_host/render_frame_host_impl.cc
@@ -1025,7 +1025,8 @@ void RenderFrameHostImpl::OnBeginNavigation(
     const CommonNavigationParams& common_params) {
   CHECK(CommandLine::ForCurrentProcess()->HasSwitch(
       switches::kEnableBrowserSideNavigation));
-  frame_tree_node()->render_manager()->OnBeginNavigation(params, common_params);
+  frame_tree_node()->navigator()->OnBeginNavigation(
+      frame_tree_node(), params, common_params);

[carlosk, 2014/10/01 18:31:10]

Noob question: if we really want to move all of navigation responsibilities out
of RFH, does it makes sense to make Navigator and IPC receiver (and maybe also
sender)? Does this implies we'll need a Navigator-mirror class running at the
renderer side?

[clamy, 2014/10/01 22:30:46]

I think it is better to keep the IPC handling in RenderFrameHost and
RenderFrame. After all, they are frame messages.

 }
 
 void RenderFrameHostImpl::OnAccessibilityEvents(