Reloading page after installing app should bring it into correct process.

content/browser/tab_contents/navigation_controller_impl.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/tab_contents/navigation_controller_impl.h"
 
 #include "base/file_util.h"
 #include "base/logging.h"
 #include "base/string_number_conversions.h"  // Temporary
 #include "base/string_util.h"
@@ skipping 248 matching lines @@
         content::NOTIFICATION_REPOST_WARNING_SHOWN,
         content::Source<NavigationController>(this),
         content::NotificationService::NoDetails());
 
     pending_reload_ = reload_type;
     tab_contents_->Activate();
     tab_contents_->GetDelegate()->ShowRepostFormWarningDialog(tab_contents_);
   } else {
     DiscardNonCommittedEntriesInternal();
 
-    pending_entry_index_ = current_index;
-    entries_[pending_entry_index_]->SetTransitionType(
-        content::PAGE_TRANSITION_RELOAD);
+    NavigationEntryImpl* entry = entries_[current_index].get();
+    SiteInstanceImpl* site_instance = entry->site_instance();
+    DCHECK(site_instance);
+
+    // If we are reloading an entry that no longer belongs to the current
+    // site instance (for example, refreshing a page for just installed app),
+    // the reload must happen in a new process.
+    // The new entry must have a new page_id and site instance, so it behaves
+    // as new navigation (which happens to clear forward history).
+    if (site_instance->HasWrongProcessForURL(entry->GetURL())) {
+      // Create a navigation entry that resembles the current one, but do not
+      // copy page id, site instance, and content state.

[darin (slow to review), 2012/01/27 19:34:11]

normally when you reload a page, webkit restores the scroll position of the
page.  however, scroll position is a property of content state.  with this
change, won't we lose scroll position?  is this desired?

[Charlie Reis, 2012/01/27 20:50:18]

It's not ideal, but I think it's reasonable in the case that a normal web page
is being reloaded after being installed as an app.  The new version of the page
may have new capabilities and should probably appear as a fresh load rather than
a normal reload.

+      NavigationEntryImpl* nav_entry = NavigationEntryImpl::FromNavigationEntry(
+          CreateNavigationEntry(
+              entry->GetURL(), entry->GetReferrer(), entry->GetTransitionType(),
+              false, entry->extra_headers(), browser_context_));
+
+      nav_entry->set_is_cross_site_reload(true);
+      pending_entry_ = nav_entry;

[darin (slow to review), 2012/01/27 19:34:11]

you don't have to set the PAGE_TRANSITION_RELOAD transition type here?

[nasko, 2012/01/27 20:14:56]

Again, due to the fact that we are transitioning processes, this is not really a
reload.

+    } else {
+      pending_entry_index_ = current_index;
+      entries_[pending_entry_index_]->SetTransitionType(
+          content::PAGE_TRANSITION_RELOAD);
+    }
+
     NavigateToPendingEntry(reload_type);
   }
 }
 
 void NavigationControllerImpl::CancelPendingReload() {
   DCHECK(pending_reload_ != NO_RELOAD);
   pending_reload_ = NO_RELOAD;
 }
 
 void NavigationControllerImpl::ContinuePendingReload() {
@@ skipping 294 matching lines @@
   } else {
     details->previous_url = GURL();
     details->previous_entry_index = -1;
   }
 
   // If we have a pending entry at this point, it should have a SiteInstance.
   // Restored entries start out with a null SiteInstance, but we should have
   // assigned one in NavigateToPendingEntry.
   DCHECK(pending_entry_index_ == -1 || pending_entry_->site_instance());
 
+  // If we are doing a cross-site reload, we need to replace the existing
+  // navigation entry, not add another entry to the history. This has the side
+  // effect of removing forward browsing history, if such existed.

[darin (slow to review), 2012/01/27 19:34:11]

normally hitting reload does not wipe out forward history.  why do we want to do
that?

[nasko, 2012/01/27 20:14:56]

Navigation entries are identified uniquely by a tuple of page id and site
instance. Since we are changing the site instance, we have potential for page id
conflicts, especially if we have forward history. Charlie and I went through all
the cases of navigating back and forth with reloads and agreed that this is the
safest approach, albeit with a bit of sacrifice in consistent behavior.

[Charlie Reis, 2012/01/27 20:50:18]

That's right.  We actually had a previous fix for this that preserved the
forward history, but it led to deeper conflicts with page IDs that caused
renderer crashes.  There's more history on http://crbug.com/80621 if you're
interested.

+  if (pending_entry_ != NULL) {
+    details->did_replace_entry = pending_entry_->is_cross_site_reload();
+  }
+
   // is_in_page must be computed before the entry gets committed.
   details->is_in_page = IsURLInPageNavigation(params.url);
 
   // Do navigation-type specific actions. These will make and commit an entry.
   details->type = ClassifyNavigation(params);
 
   switch (details->type) {
     case content::NAVIGATION_TYPE_NEW_PAGE:
       RendererDidNavigateToNewPage(params, &(details->did_replace_entry));
       break;
@@ skipping 769 matching lines @@
   for (int i = 0; i < max_index; i++) {
     // When cloning a tab, copy all entries except interstitial pages
     if (source.entries_[i].get()->GetPageType() !=
         content::PAGE_TYPE_INTERSTITIAL) {
       entries_.insert(entries_.begin() + insert_index++,
                       linked_ptr<NavigationEntryImpl>(
                           new NavigationEntryImpl(*source.entries_[i])));
     }
   }
 }