Add a unique frame id and save it on HistoryItem.

Source/core/frame/Frame.h

Index: Source/core/frame/Frame.h
diff --git a/Source/core/frame/Frame.h b/Source/core/frame/Frame.h
index 0937f95e287c1a3e1e88a4f141d197eb050f750e..aabd1b9f82f20dc8f77fc6e21cddbfb2c4d8f0c8 100644
--- a/Source/core/frame/Frame.h
+++ b/Source/core/frame/Frame.h
@@ -112,6 +112,8 @@ namespace WebCore {
 
         void dispatchVisibilityStateChangeEvent();
 
+        int64_t id() const { return m_id; }

[Charlie Reis, 2013/10/29 22:35:03]

It would probably help to document the scope of this ID (e.g., per process or
unique across all processes).

Looks like it's specific to this renderer, so I'm not sure how this fits into
the plans yet.  We already have both a routing ID and a
WebFrame::embedderIdentifier for each frame that are renderer-specific, and this
is a third ID.  Soon we'll have a browser-wide FrameTreeNode ID in the browser
process as well.

Our intention was to eliminate WebFrame::embedderIdentifier in favor of the
routing ID, so that we have two IDs per frame (renderer-specific routing ID and
browser-global FrameTreeNode ID).  Do we need this additional one long term, or
is it a stepping stone?  Can we get rid of WebFrame::embedderIdentifier if we
have this?

+
     // ======== All public functions below this point are candidates to move out of Frame into another class. ========
 
         bool inScope(TreeScope*) const;
@@ -187,6 +189,8 @@ namespace WebCore {
         OwnPtr<AnimationController> m_animationController;
         OwnPtr<InputMethodController> m_inputMethodController;
 
+        int64_t m_id;
+
         float m_pageZoomFactor;
         float m_textZoomFactor;