Additional fixes for prerender/instant + browsing history.

content/browser/tab_contents/tab_contents.cc

Index: content/browser/tab_contents/tab_contents.cc
diff --git a/content/browser/tab_contents/tab_contents.cc b/content/browser/tab_contents/tab_contents.cc
index 0b06b975200dce0dce4aec261d136bed54ff41aa..c57c590f993fdcfc32ad3ea8edeaa42a87619648 100644
--- a/content/browser/tab_contents/tab_contents.cc
+++ b/content/browser/tab_contents/tab_contents.cc
@@ -596,12 +596,16 @@ bool TabContents::NavigateToEntry(
   return true;
 }
 
-void TabContents::SetHistoryLengthAndClear(int history_length) {
+void TabContents::SetHistoryLengthAndPrune(const SiteInstance* site_instance,
+                                           int history_length,
+                                           int32 minimum_page_id) {
   RenderViewHost* rvh = render_view_host();
   if (!rvh)
     return;
-  rvh->Send(new ViewMsg_SetHistoryLengthAndClear(rvh->routing_id(),
-                                                 history_length));
+  DCHECK(!site_instance || rvh->site_instance() == site_instance);

[Charlie Reis, 2011/08/13 00:29:04]

I'm wary about not having an early return in release builds, but I'm ok with it
as is if we can understand why it isn't necessary.

Is the intention that we only call this on TabContents that are about to be
swapped in from prerendering or instant, and thus they won't have a pending
entry?  If so, let's add a DCHECK that
render_manager_.pending_render_view_host() is null.

[cbentzel, 2011/08/13 02:19:12]

Actually, some of them may have a pending entry - this could be the case if a
prerender is swapped in before the first page is committed. However, in that
case render_view_host_ is non-NULL and is the actual host for the RenderView
that the prerender is taking place on.

The case we need to worry about is when there is a pending_render_view_host_ due
to render-issued cross-SiteInstance navigations. In the Instant case this is
restricted enough to not happen, but on the prerender case it may be possible.

I will have to think some more about how to handle that. Arguably we could
cancel the pending entry and only send to render_view_host_. 

[Charlie Reis, 2011/08/13 06:26:27]

Oops, I meant to say "pending RenderViewHost" rather than "pending entry."
Yes, I think an attempt to start a cross-site transition from a prerender
TabContents should cancel the prerendering.  You're right that a
renderer-initiated navigation could cause it, such as navigating to a URL that's
installed as an app.

+  rvh->Send(new ViewMsg_SetHistoryLengthAndPrune(rvh->routing_id(),
+                                                 history_length,
+                                                 minimum_page_id));
 }
 
 void TabContents::Stop() {