ntp4: improved app install, try 2

chrome/browser/extensions/extension_install_ui.cc

Index: chrome/browser/extensions/extension_install_ui.cc
diff --git a/chrome/browser/extensions/extension_install_ui.cc b/chrome/browser/extensions/extension_install_ui.cc
index 0717acd7bedda56e47625d2acced774b713bce99..34d2e9c2fd067ecf479166d725b29e5543a05deb 100644
--- a/chrome/browser/extensions/extension_install_ui.cc
+++ b/chrome/browser/extensions/extension_install_ui.cc
@@ -235,8 +235,12 @@ void ExtensionInstallUI::OpenAppInstalledNTP(Browser* browser,
       "%s#app-id=%s", chrome::kChromeUINewTabURL, app_id.c_str());

[Rick Byers, 2011/08/29 16:01:00]

Why do you still need the code for setting and reading the hash?  I would have
thought that supporting the "already open NTP" case with the notification could
also easily handle the case where no NTP is open.  It's confusing having two
different channels for the information about which app to highlight....

[Evan Stade, 2011/08/29 18:15:16]

hmm. I tried to do what you're suggesting and it didn't work, so I assumed that
the new AppLauncherHandler wasn't being constructed till after this notification
(i.e. that Navigate wasn't creating it synchronously), although now that I test
construction order explicitly that doesn't seem to be the case. I'll see if I
can fix it because I agree the #app-id hack is annoying.

   browser::NavigateParams params =
       browser->GetSingletonTabNavigateParams(GURL(url));
-  params.path_behavior = browser::NavigateParams::IGNORE_AND_NAVIGATE;
   browser::Navigate(&params);
+
+  NotificationService::current()->Notify(
+      chrome::NOTIFICATION_APP_INSTALLED_TO_NTP,
+      Source<TabContents>(params.target_contents->tab_contents()),
+      Details<const std::string>(&app_id));
 }
 
 // static