Fix regression with back-button not working on prerendered and instant pages.

content/browser/tab_contents/navigation_controller.cc

Index: content/browser/tab_contents/navigation_controller.cc
diff --git a/content/browser/tab_contents/navigation_controller.cc b/content/browser/tab_contents/navigation_controller.cc
index e29ecc31ded29d91e7b56219710a56d94a821cfe..1a44ae1c5718ea055b81a2469c63dc8270ef70c2 100644
--- a/content/browser/tab_contents/navigation_controller.cc
+++ b/content/browser/tab_contents/navigation_controller.cc
@@ -931,6 +931,9 @@ void NavigationController::CopyStateFromAndPrune(NavigationController* source,
     if (last_committed_entry_index_ != -1)
       last_committed_entry_index_--;
   }
+
+  // Update the history in the RenderView.
+  tab_contents_->SetHistoryLengthAndClear(entry_count() - 1);

[Charlie Reis, 2011/08/09 20:59:31]

There's some hidden assumptions here that make me a little uneasy about putting
this call here.  The comments on CopyStateFromAndPrune seem to suggest this is
somewhat general, but this call assumes all previous entries were not rendered
by the current RenderViewHost and can thus be marked -1.

Just wondering if we should update the comment or contract to say this method is
explicitly for preparing a TabContents to be swapped in.

Outside of that, are we guaranteed this message will be sent before the new
TabContents has a chance to do a history.back() or history.forward()?  Otherwise
that could lead to a race.

[cbentzel, 2011/08/09 21:21:12]

We chatted about history.back() and history.forward() for the prerendered page.
In general these should be no-ops, but I don't think we handle the case where
history.pushState or location setting takes place with this well. 

 }
 
 void NavigationController::PruneAllButActive() {