mus/chrome: Always wait for the mojo shell.

content/browser/browser_main_loop.cc

Index: content/browser/browser_main_loop.cc
diff --git a/content/browser/browser_main_loop.cc b/content/browser/browser_main_loop.cc
index d55a7f7d8e466f7f02ab0833ea59011203971a11..96877f59b1b1cd624c00e47cea4168ec8902f2bb 100644
--- a/content/browser/browser_main_loop.cc
+++ b/content/browser/browser_main_loop.cc
@@ -298,7 +298,16 @@ static void SetUpGLibLogHandler() {
                       NULL);
   }
 }
-#endif
+#endif  // defined(USE_GLIB)
+
+#if defined(MOJO_SHELL_CLIENT) && defined(USE_AURA)
+void WaitForMojoShellInitialize() {
+  base::RunLoop wait_loop;
+  MojoShellConnectionImpl::Get()->shell_connection()->set_initialize_handler(
+      wait_loop.QuitClosure());
+  wait_loop.Run();
+}
+#endif  // defined(MOJO_SHELL_CLIENT) && defined(USE_AURA)
 
 void OnStoppedStartupTracing(const base::FilePath& trace_file) {
   VLOG(0) << "Completed startup tracing to " << trace_file.value();
@@ -1190,6 +1199,7 @@ int BrowserMainLoop::BrowserThreadsStarted() {
 #if defined(MOJO_SHELL_CLIENT) && defined(USE_AURA)
     MojoShellConnection* mojo_shell_connection = MojoShellConnection::Get();
     if (mojo_shell_connection) {
+      WaitForMojoShellInitialize();

[Ken Rockot(use gerrit already), 2016/04/26 03:28:55]

Do you think there may ever be a future where we can avoid blocking startup on
this connection? IIRC this is only needed because mus (or the window server, or
mus client code or... something, I don't remember) itself needs to completely
block the main thread until it receives some message, and that message can't be
received unless the shell connection has been initialized (which of course can't
happen while the main thread is blocked).

If this might be possible to avoid, please preserve my TODO from the other file
here. If not, I would like to understand why.

[sadrul, 2016/04/26 03:43:35]

I have added back the TODO.

It might be possible to avoid the blocking behaviour of
WindowManagerConnection/ScreenMus. One way would be to init with a default set
if displays in ScreenMus, and update local state when the mus-server sends back
information about the real set of displays to it asynchronously (instead of
blocking on the response). I plan on trying this out and see how well, if at
all, it works.

       views::WindowManagerConnection::Create(
           mojo_shell_connection->GetConnector(),
           mojo_shell_connection->GetIdentity());