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

chrome/renderer/chrome_content_renderer_client.cc

Index: chrome/renderer/chrome_content_renderer_client.cc
diff --git a/chrome/renderer/chrome_content_renderer_client.cc b/chrome/renderer/chrome_content_renderer_client.cc
index caa538279512bf270964417c5d867533e231f46c..0238bda5f6c3766afb498cdb15dd3b6d7f26ff58 100644
--- a/chrome/renderer/chrome_content_renderer_client.cc
+++ b/chrome/renderer/chrome_content_renderer_client.cc
@@ -756,6 +756,16 @@ bool ChromeContentRendererClient::CrossesExtensionExtents(
   const Extension* new_url_extension = extensions::GetNonBookmarkAppExtension(
       *extensions, ExtensionURLInfo(new_url));
 
+  // If this is a reload, check whether it has the wrong process type.  We
+  // should send it to the browser if it's an extension URL (e.g., hosted app)
+  // in a normal process, or if it's a process for an extension that has been
+  // uninstalled.
+  if (old_url == new_url) {

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

This condition isn't necessarily limited to a reload.  You can also get this by
hitting enter in the location bar.

(Generally, reload is reserved to correspond to clicking the "reload" button.)

Also, are you sure comparing URLs is enough?  Maybe we should be comparing site
instances?  What about if the URLs are the same but only differ in terms of
their reference fragment?

Also, isn't this abusing the meaning of CrossesExtensionExtents?  It seems like
if the before and after URL are identical, then it cannot possibly cross
extension extents.  Is this function misnamed?  Given the current name, I
wouldn't be surprised if the caller performed an URL equivalency test as a
short-cut around having to call this function.

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

Hitting enter in the location bar is handled by the browser process, as well as
clicking on the reload button. This class is running in the renderer process, so
it doesn't come into picture for those two actions.

Site instance data is also not available in the renderer process, so we can't
really compare them. This code is added to handle renderer initiated reloads,
one instance of which is dong location.reload() in JS. I've discussed with
Charlie that we need better way to express privilege level for renderer
processes, so they can make decision whether to route top level navigation
events to the browser or not. Until we do this work, we can handle JS reload
here. So yes, I agree this can be much better, but it is a much bigger effort,
belonging to a separate issue.

[darin (slow to review), 2012/01/27 23:58:35]

^^^ what about this last point?  is this really the right location for this?

[nasko, 2012/01/28 01:43:12]

It could be moved to the function that calls this, which is named more
appropriately (ShouldFork), though we are indeed crossing a boundary, which
involves time. If you believe it is better in the caller, I'd be happy to move
it. I'm still trying to learn the componentization and how things fit together :
).

+    bool is_extension_url = !!new_url_extension;
+    if (is_extension_url != extension_dispatcher_->is_extension_process())
+      return true;

[darin (slow to review), 2012/01/27 23:58:35]

what about the reverse case?  what if the app is uninstalled and the reloaded?

[nasko, 2012/01/28 01:43:12]

Yes, if the process "type" mismatches with the current expectation, it will
detect it and route to the browser.

+  }
+
   // If old_url is still empty and this is an initial navigation, then this is
   // a window.open operation.  We should look at the opener URL.
   if (is_initial_navigation && old_url.is_empty() && frame->opener()) {