c++ / mojo changes for 'external window mode'

services/ui/demo/window_tree_data.cc

Index: services/ui/demo/window_tree_data.cc
diff --git a/services/ui/demo/window_tree_data.cc b/services/ui/demo/window_tree_data.cc
index 3d78c94df668343d7eb38d73ca32305ff5fd923c..65055a8a6dfe65f1b10cba3f2f625bbb9d0fcde5 100644
--- a/services/ui/demo/window_tree_data.cc
+++ b/services/ui/demo/window_tree_data.cc
@@ -68,10 +68,11 @@ aura::Window* WindowTreeData::bitmap_window() {
 
 void WindowTreeData::Init(
     std::unique_ptr<aura::WindowTreeHostMus> window_tree_host) {
-  window_tree_host->InitHost();
-  window_tree_host->Show();
-  // Take ownership of the WTH.
-  window_tree_host_ = std::move(window_tree_host);
+  if (window_tree_host) {

[kylechar, 2017/03/07 18:19:36]

When would |window_tree_host| be null?

[tonikitoo, 2017/03/07 20:09:36]

Before this CL, all the ws::Display creation happened on the server side first,
and only upon finishing it, WindowTreeClient::OnEmbed was called.
In sequence, WindowTreeClient::OnEmbedImpl was called, and then
WindowTreeClient::CreateWindowTreeHost.

Only at this point, with the WindowClientHostMus instance available, that
MusDemo::OnEmbed was called, taking the WindowTreeHostMus instance as parameter.

See
https://cs.chromium.org/chromium/src/ui/aura/mus/window_tree_client.cc?q=Wind...


In 'external window mode', it is MusDemoExternal that actually creates on
WindowTreeHostMus instances.
So, when MusDemo::OnEmbed is called, it does not need to pass an
WindowTreeHostMus instance because it was already created. 

This can be clearer when we introduce ::OnEmbedRootReady to be called here,
instead of ::OnEmbed.

+    window_tree_host->InitHost();
+    window_tree_host->Show();
+    SetWindowTreeHost(std::move(window_tree_host));
+  }
 
   // Initialize the window for the bitmap.
   window_delegate_ = new aura_extra::ImageWindowDelegate();