Export GetLastCommittedEntryIndex and RemoveEntryAtIndex to Java layer

content/browser/frame_host/navigation_controller_android.h

Index: content/browser/frame_host/navigation_controller_android.h
diff --git a/content/browser/frame_host/navigation_controller_android.h b/content/browser/frame_host/navigation_controller_android.h
index 9b642dcd9a1ac3e6e5d7ac3df8b8318330387bd7..9b9a8c6706244d5a5a3146c199857ce09a09d9af 100644
--- a/content/browser/frame_host/navigation_controller_android.h
+++ b/content/browser/frame_host/navigation_controller_android.h
@@ -77,6 +77,8 @@ class CONTENT_EXPORT NavigationControllerAndroid {
   base::android::ScopedJavaLocalRef<jstring>
       GetOriginalUrlForVisibleNavigationEntry(JNIEnv* env, jobject obj);
   void ClearHistory(JNIEnv* env, jobject obj);
+  int GetLastCommittedEntryIndex(JNIEnv* env, jobject obj);
+  jboolean RemoveEntryAtIndex(JNIEnv* env, jobject obj, jint index);

[Charlie Reis, 2014/10/29 17:06:47]

Just curious, why do you need RemoveEntryAtIndex?  Anything that removes entries
at an arbitrary position is a bit subtle in practice, so I'd like to be sure
there's a good reason for it.  (We've had to restrict the Prune methods using
CanPruneAllButLastCommitted, for example.)

(Also, I think I just spotted a bug in that method: it doesn't update the
pending_entry_index_ after removal.  I'll file and fix that, though.)

[Charlie Reis, 2014/10/29 20:20:55]

For reference, I filed http://crbug.com/428380 for it.  It turns out it's not
buggy but has potentially unexpected behavior: it clears the pending entry. 
That may affect your use case, which is part of why I'm curious about it.

 
  private:
   NavigationController* navigation_controller_;