mus/chrome: Always wait for the mojo shell.

content/common/mojo/mojo_shell_connection_impl.cc

Index: content/common/mojo/mojo_shell_connection_impl.cc
diff --git a/content/common/mojo/mojo_shell_connection_impl.cc b/content/common/mojo/mojo_shell_connection_impl.cc
index 8f7f735afeb855140191147fac80662be19166dd..1f9338693964e47d3accc1f2a58326b108bd3b35 100644
--- a/content/common/mojo/mojo_shell_connection_impl.cc
+++ b/content/common/mojo/mojo_shell_connection_impl.cc
@@ -40,10 +40,7 @@ bool IsRunningInMojoShell() {
 }
 
 bool ShouldWaitForShell() {
-  return mojo_shell_connection_factory ||
-         (IsRunningInMojoShell() &&
-          base::CommandLine::ForCurrentProcess()->HasSwitch(
-              switches::kWaitForMojoShell));
+  return mojo_shell_connection_factory || IsRunningInMojoShell();

[Ken Rockot(use gerrit already), 2016/04/25 23:29:35]

Unfortunately IsRunningInMojoShell is a misnomer, as it looks for a flag which
is used for reasons other than running in Mojo shell. For example, content child
processes get this flag set by the browser process when launched. It should
really be called HasShellClientRequestOnCommandLine or something.

We do not want content child processes waiting for the Mojo shell. We need some
other way to detect if we're running in an external shell, and that's what
--wait-for-mojo-shell was for. Can we somehow force this flag to be present in
the cases we care about?

[sadrul, 2016/04/26 03:22:04]

I was thinking a naive workaround would be to check for the process-type as well
... but I have done things a bit differently in the latest patchset: from
reading https://crrev.com/381182, it sounds like we need to wait for the
initialization only because of how we initialize views
(views::WindowManagerConnection, which initializes views::ScreenMus, which does
another blocking call to mojo:mus), and so I moved the 'wait for initialization'
in the same place where we create this views::WindowManagerConnection object, in
BrowserMainLoop (just before WindowManagerConnection is creted). This means none
of the child processes ever block, and the browser process only blocks when
running inside of mus. I think this takes care of the concerns? (if not, I will
add the cmd-flag explicitly in the test and other such cases where we need to,
but I thought I would give this one more try)

 }
 
 // static