Start app shim when app launched.

chrome/browser/extensions/platform_app_launcher.cc

Index: chrome/browser/extensions/platform_app_launcher.cc
diff --git a/chrome/browser/extensions/platform_app_launcher.cc b/chrome/browser/extensions/platform_app_launcher.cc
index 8e22447e8a1e304a9124a7d68722265568491123..be14608ed727e5d50056301399559838a7be786d 100644
--- a/chrome/browser/extensions/platform_app_launcher.cc
+++ b/chrome/browser/extensions/platform_app_launcher.cc
@@ -22,6 +22,7 @@
 #include "chrome/browser/extensions/lazy_background_task_queue.h"
 #include "chrome/browser/profiles/profile.h"
 #include "chrome/browser/ui/extensions/app_metro_infobar_delegate_win.h"
+#include "chrome/browser/web_applications/web_app.h"
 #include "chrome/common/extensions/extension.h"
 #include "chrome/common/extensions/extension_messages.h"
 #include "content/public/browser/browser_thread.h"
@@ -90,12 +91,15 @@ bool GetAbsolutePathFromCommandLine(const CommandLine* command_line,
   return true;
 }
 
+void DoNothing(bool) {}
+
 // Helper method to launch the platform app |extension| with no data. This
 // should be called in the fallback case, where it has been impossible to
 // load or obtain file launch data.
 void LaunchPlatformAppWithNoData(Profile* profile, const Extension* extension) {
   DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
   extensions::AppEventRouter::DispatchOnLaunchedEvent(profile, extension);
+  web_app::LaunchShim(profile, extension, base::Bind(&DoNothing));

[jackhou1, 2013/05/17 05:49:33]

Should we just let the shim do the launch?

[benwells, 2013/05/17 05:59:41]

One downside is that if there is any problem with the shim, the app won't
launch.

[tapted, 2013/05/17 06:44:00]

So non committal ;). But won't we need to handle that case any way? That is, if
providing icons in the dock becomes default, any situation that could cause the
icon not to appear would be a bug.

My current feeling is that, on balance, having the browser initiate the launch
might be trickier. You need to handle the race condition, where the shim
connects after the app has started and immediately closed. It might also be
weird having the app window appear before the dock icon in some cases.

Actually, I've realised another tricky aspect. It's perfectly fine launching an
app multiple times from the NTP. In most cases, you just get multiple windows
(unless the app creates windows with an `id`).

So, one question is: what should a shim do? I *think* OSX will ignore the second
launch attempt, but send the shim process an OS event instead, like OnRestart.
This could be forwarded to the already-running shim host, which I don't think
currently happens.

Back to this, I think the path via LaunchPlatformAppWithNoData also needs a
check for is-shim-already-running. If the browser is sending OnLaunched, I don't
think it should try to start another shim in this case.

In either case, the shim host needs to be aware that there could be multiple
windows open for a given connection.

So, that's a fairly non-committal answer as well. Maybe we start with whatever
works (ie: this), and get feedback when people try it out.

[benwells, 2013/05/21 03:14:47]

Well, I trust you guys know more about the ins and outs of implementing this ...
as you've just demonstrated :)

But, your explanations have helped me get more committal:
- I'd prefer to keep launching apps independent of shims. Just from a
flexibility point of view: it is better to be able to remove or replace shims
and have everything else just work.
- If there are races avoiding them like this will probably* just make them
appear somewhere else.
- What happens if the user deletes the shim?

* generalization which may be incorrect in this case.

Also, we should make NTP / launcher / shim behavior consistent across platforms
(or decide not to). I wouldn't worry about it for now.

 }
 
 // Class to handle launching of platform apps to open a specific path.