PlzNavigate: implement CommitNavigation on the browser side

content/browser/frame_host/navigation_parameters.h

+// Copyright 2014 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.
+
+#ifndef CONTENT_BROWSER_FRAME_HOST_NAVIGATION_PARAMETERS_H_
+#define CONTENT_BROWSER_FRAME_HOST_NAVIGATION_PARAMETERS_H_
+
+#include <string>
+
+#include "base/basictypes.h"
+#include "base/time/time.h"
+#include "content/common/frame_message_enums.h"
+#include "content/public/common/page_state.h"
+#include "content/public/common/page_transition_types.h"
+#include "content/public/common/referrer.h"
+#include "url/gurl.h"
+struct FrameHostMsg_BeginNavigation_Params;
+struct FrameMsg_CommitNavigation_Params;
+
+namespace content {
+class NavigationControllerImpl;
+class NavigationEntryImpl;
+struct NavigationBeforeCommitInfo;
+
+// PlzNavigate
+// This class holds parameters for a Navigation. It is first created when the

[(Do not use) nasko, 2014/09/05 17:04:48]

nit: "navigation", no need to uppercase.

+// the navigation is requested, then updated when the navigation begins and when

[(Do not use) nasko, 2014/09/05 17:04:48]

In the case of renderer initiated, there will be no "request" for navigation,
right?

+// the navigation is ready to commit.
+class NavigationParameters {

[clamy, 2014/09/03 22:23:44]

Disclaimer: if you have a great name for that class I'd be happy to hear it :).

[(Do not use) nasko, 2014/09/05 17:04:48]

I don't have anything greater than what you've already come up with : ).

+ public:
+  NavigationParameters(const NavigationEntryImpl& entry,
+                       NavigationControllerImpl* controller,
+                       base::TimeTicks navigation_start,
+                       FrameMsg_Navigate_Type::Value navigation_type);
+  ~NavigationParameters();
+
+  bool allow_download() const { return allow_download_; }
+  FrameMsg_Navigate_Type::Value navigation_type_for_testing() const {
+    return navigation_type_;
+  }
+
+  void UpdateFromBeginNavigationParams(

[(Do not use) nasko, 2014/09/05 17:04:48]

nit: I'd drop the "Params" part of the name, it is clear in the parameter list.

+      const FrameHostMsg_BeginNavigation_Params& begin_navigation_params);
+  void UpdateFromCommitInfo(const NavigationBeforeCommitInfo& commit_info);
+
+  // Simulates the response from the renderer when there is no live renderer.
+  FrameHostMsg_BeginNavigation_Params SimulateRendererResponse() const;

[(Do not use) nasko, 2014/09/05 17:04:48]

Is this intended for tests? Or temporary? It should be clear what the purpose
is, as I doubt we want this to stick around in the long term.

+
+  FrameMsg_CommitNavigation_Params MakeCommitNavigationParams() const;
+
+ private:
+  // The URL to navigate to. May be modified when th enavigation is ready to

[(Do not use) nasko, 2014/09/05 17:04:48]

"the navigation"

+  // commit.
+  GURL url_;
+
+  // The URL to request to the browser to get access to the stream of data.

[(Do not use) nasko, 2014/09/05 17:04:48]

nit: "The URL the renderer should request from the browser ..."

+  GURL stream_url_;
+
+  bool is_post_;

[(Do not use) nasko, 2014/09/05 17:04:48]

comment?

+
+  // The page_id for this navigation, or -1 if it is a new navigation.  Back,
+  // Forward, and Reload navigations should have a valid page_id.  If the load
+  // succeeds, then this page_id will be reflected in the resultant
+  // FrameHostMsg_DidCommitProvisionalLoad message.
+  int32 page_id_;
+
+  // Informs the RenderView the session history should be cleared. In that

[(Do not use) nasko, 2014/09/05 17:04:48]

nit: Let's start using RenderFrame in all new code/comments. Even if we
currently use RenderView, at least comments should mention RenderFrame, since
later refactor can miss the comments and they will diverge.

+  // case, the RenderView needs to notify the browser that the clearing was
+  // succesful when the navigation commits.
+  bool should_clear_history_list_;
+
+  // If page_id is -1, then pending_history_list_offset will also be -1.
+  // Otherwise, it contains the offset into the history list corresponding to
+  // the current navigation.
+  int pending_history_list_offset_;
+
+  // Used to inform the RenderView of where its current page contents reside in
+  // session history and the total size of the session history list.
+  int current_history_list_offset_;
+  int current_history_list_length_;
+
+  // The URL to send in the "Referer" header field. Can be empty if there is
+  // no referrer.
+  Referrer referrer_;
+
+  // The type of transition.
+  PageTransition transition_;
+
+  // Opaque history state (received by ViewHostMsg_UpdateState).
+  PageState page_state_;
+
+  // Type of navigation.
+  FrameMsg_Navigate_Type::Value navigation_type_;
+
+  // Whether or not the user agent override string should be used.
+  bool is_overriding_user_agent_;
+
+  // Whether this navigation should replace the current session history entry on
+  // commit.
+  bool should_replace_current_entry_;
+
+  // Whether or not we should allow the URL to download.
+  bool allow_download_;
+
+  // The navigationStart time to expose through the Navigation Timing API to JS.
+  base::TimeTicks browser_navigation_start_;

[(Do not use) nasko, 2014/09/05 17:04:48]

This is mostly a copy of FrameMsg_Navigate_Params. The initial thought was to
split parameters that are sent through IPCs in two sets - one specific to each
event (begin/commit) and the other being the common parameters we always send
around. This way we can follow the flow of data between processes and avoid
duplicating it all.

[clamy, 2014/09/05 18:21:25]

So if we split up the IPCs in having some sort of core parameter (that contains
thing like history parameters, page id etc...) would you prefer if we store one
of those here rather than the separate parameters themselves?

+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_FRAME_HOST_NAVIGATION_PARAMETERS_H_