Add item and document sequence numbers to FrameNavigationEntry.

content/public/common/frame_navigate_params.h

Index: content/public/common/frame_navigate_params.h
diff --git a/content/public/common/frame_navigate_params.h b/content/public/common/frame_navigate_params.h
index 884a1d1b6d2ff76eb9debc05e0ee453d34908f01..8a2ba41e1a4f6b6b149ce7356893dc7470fb243c 100644
--- a/content/public/common/frame_navigate_params.h
+++ b/content/public/common/frame_navigate_params.h
@@ -33,6 +33,16 @@ struct CONTENT_EXPORT FrameNavigateParams {
   // means. If the navigation was renderer-initiated, this value is 0.
   int nav_entry_id;
 
+  // The item sequence number identifies each stop in the session history
+  // and is globally unique.
+  int64 item_sequence_number;
+
+  // The document sequence number is ssed to identify cross-document navigations
+  // in session history.  It increments for each new document and is globally
+  // unique.  In-page navigations get a new item sequence number but the same
+  // document sequence number.
+  int64 document_sequence_number;
+

[Avi (use Gerrit), 2015/06/18 00:57:00]

If these are generated deep in Blink in a renderer process (coming off of
WebHistoryItem), how in the world are they supposed to end up being "globally
unique"?

[Charlie Reis, 2015/06/18 20:30:18]

They get serialized into session restore data, so I think the goal was for them
to still be usable when restored into a new session.  Looking closer, it's not
actually guaranteed-- it's just an attempt to avoid overlap:

static long long generateSequenceNumber()
{
    // Initialize to the current time to reduce the likelihood of generating
    // identifiers that overlap with those from past/future browser sessions.
    static long long next = static_cast<long long>(currentTime() * 1000000.0);
    return ++next;
}

I've rephrased the comment, and I'll be sure to include a SiteInstance check
when comparing them for navigation.

   // URL of the page being loaded.
   GURL url;