Switch the history backend from using page ids to navigation entry unique ids.

components/history/core/browser/visit_tracker.cc

Index: components/history/core/browser/visit_tracker.cc
diff --git a/components/history/core/browser/visit_tracker.cc b/components/history/core/browser/visit_tracker.cc
index 71d772ff94808b7299ccd0e177e7e56dda797ac8..4738989ed9d1c0796c5b2eba0e97f86a55bb7fa8 100644
--- a/components/history/core/browser/visit_tracker.cc
+++ b/components/history/core/browser/visit_tracker.cc
@@ -29,7 +29,7 @@ VisitTracker::~VisitTracker() {
 // deal. However, if this ends up being noticable for performance, we may want
 // to optimize lookup.
 VisitID VisitTracker::GetLastVisit(ContextID context_id,
-                                   int32 page_id,
+                                   int nav_entry_id,
                                    const GURL& referrer) {
   if (referrer.is_empty() || !context_id)
     return 0;
@@ -39,24 +39,26 @@ VisitID VisitTracker::GetLastVisit(ContextID context_id,
     return 0;  // We don't have any entries for this context.
   TransitionList& transitions = *i->second;
 
-  // Recall that a page ID is associated with a single session history entry.
-  // In the case of automatically loaded iframes, many visits/URLs can have the
-  // same page ID.
+  // Recall that a navigation entry ID is associated with a single session
+  // history entry. In the case of automatically loaded iframes, many
+  // visits/URLs can have the same navigation entry ID.
   //
-  // We search backwards, starting at the current page ID, for the referring
-  // URL. This won't always be correct. For example, if a render process has
-  // the same page open in two different tabs, or even in two different frames,
-  // we can get confused about which was which. We can have the renderer
-  // report more precise referrer information in the future, but this is a
-  // hard problem and doesn't affect much in terms of real-world issues.
+  // We search backwards, starting at the current navigation entry ID, for the
+  // referring URL. This won't always be correct. For example, if a render
+  // process has the same page open in two different tabs, or even in two
+  // different frames, we can get confused about which was which. We can have
+  // the renderer report more precise referrer information in the future, but
+  // this is a hard problem and doesn't affect much in terms of real-world
+  // issues.
   //
-  // We assume that the page IDs are increasing over time, so larger IDs than
-  // the current input ID happened in the future (this will occur if the user
-  // goes back). We can ignore future transitions because if you navigate, go
-  // back, and navigate some more, we'd like to have one node with two out
-  // edges in our visit graph.
+  // We assume that the navigation entry IDs are increasing over time, so larger
+  // IDs than the current input ID happened in the future (this will occur if
+  // the user goes back). We can ignore future transitions because if you
+  // navigate, go back, and navigate some more, we'd like to have one node with
+  // two out edges in our visit graph.
   for (int i = static_cast<int>(transitions.size()) - 1; i >= 0; i--) {
-    if (transitions[i].page_id <= page_id && transitions[i].url == referrer) {
+    if (transitions[i].nav_entry_id <= nav_entry_id &&
+            transitions[i].url == referrer) {
       // Found it.
       return transitions[i].visit_id;
     }
@@ -67,7 +69,7 @@ VisitID VisitTracker::GetLastVisit(ContextID context_id,
 }
 
 void VisitTracker::AddVisit(ContextID context_id,
-                            int32 page_id,
+                            int nav_entry_id,
                             const GURL& url,
                             VisitID visit_id) {
   TransitionList* transitions = contexts_[context_id];
@@ -78,7 +80,7 @@ void VisitTracker::AddVisit(ContextID context_id,
 
   Transition t;
   t.url = url;
-  t.page_id = page_id;
+  t.nav_entry_id = nav_entry_id;
   t.visit_id = visit_id;
   transitions->push_back(t);