New TimeToFirstURLJob* navigation metrics now work with PlzNavigate.

content/browser/frame_host/navigation_request.cc

Index: content/browser/frame_host/navigation_request.cc
diff --git a/content/browser/frame_host/navigation_request.cc b/content/browser/frame_host/navigation_request.cc
index 34647b93f93e788ec9e81f797a86526d1bdf3da4..7625914c3bbf27c610fd78a428b38bdd8e23423c 100644
--- a/content/browser/frame_host/navigation_request.cc
+++ b/content/browser/frame_host/navigation_request.cc
@@ -108,7 +108,12 @@ void NavigationRequest::OnRequestFailed(int net_error) {
   DCHECK(state_ == STARTED);
   state_ = FAILED;
   // TODO(davidben): Network failures should display a network error page.
-  NOTIMPLEMENTED();
+  NOTIMPLEMENTED() << " where net_error=" << net_error;
+}
+
+void NavigationRequest::NavigationRequested(base::TimeTicks timestamp) {
+  frame_tree_node_->navigator()->LogResourceRequestTime(timestamp,
+                                                        common_params_.url);

[davidben, 2015/01/28 21:33:26]

This is just measuring the time to do two thread hops, FWIW.

[carlosk, 2015/01/30 14:01:46]

In fact I think we'll actually be measuring a single thread hop, from the UI
thread to the IO thread as the timestamp is obtained before we jump back to the
UI. :)

But yes, we want to measure the time between the navigation request creation and
the first (potential) network request is made, which is what
Navigation.TimeToURLFirstJob* histograms are supposed to track. The expectation
with PlzNavigate is that this will see a significant speed boost in comparison
with the current navigation.

I also considered moving the logging point further down into the call chain so
that both logs (with or without PlzNavigate) happen at the same trigger point
but that would incur too much plumbing of stuff as the way each log case happens
is very different.

 }
 
 }  // namespace content