Antonio Gomes authored Mar 22, 2017 and Santosh Mahto committed Nov 22, 2017

This CL is the first step towards having 'external window mode' support
in Mus. The existing MusDemo is adapted to test the functionality,
and its respective unit test (mus_demo_unittests) is changed to
exercise  multiple external windows creation in a follow up CL [2].

[2] https://codereview.chromium.org/2715533005/

New code flow:

* MusDemoExternal creates and holds a WindowTreeClient instance.

Note: In Chrome, it also happens in
c/b/ui/views/chrome_browser_main_extra_parts_views.cc,
::ServiceManagerConnectionStarted, when MusClient is created.

* MusDemoExternal calls WindowTreeClient::ConnectViaWindowTreeHostFactory.
This "enters" WindowTreeClient in 'external window mode', and
creates a WindowTreeHostFactoryRegistrar instance.
Through this object, WindowTreeHostFactoryRegistrar::Register is
called, creating WindowTree and WindowTreeHostFactory instances on
the server side, and acquiring WindowTree and
WindowTreeHostFactory mojo handles on the client side.

Note: In external window mode, the WindowTree and WindowTreeHostFactory
are unique instances, serving 0 or 'n' WindowTreeHostMus instances.

* Yet from MusDemoExternal, WindowTreeHostMus instance(s) are
created, in accordance to the value passed to command line
parameter --external-window-count, or 1 by default.

Note: In Chrome, this happens in
c/b/ui/views/frame/browser_frame_mus.cc, ::GetWidgetParams when
DesktopWindowTreeHostMus is created for each outer platform window.

WindowTreeHostMus ctor takes a WindowTreeClient instance which
works as a "window tree host delegate".

* During the creation chain of WindowTreeHostMus, WindowTreeClient::CreateWindowPortForTopLevel
is called, and this is what calls the newly added method
WindowTreeHostFactory::CreatePlatformWindow, when in 'external
window mode'. That is the entry point of of ws::Display instance
creation.

* In the existing creation flow of ws::Display, the server
actually calls back to the client via WindowTreeClient::OnEmbed
when it is done. In 'external window mode' this callback is kept,
but it passes a 'null' WindowTree object as parameter.
Why? Because in ::ConnectViaWindowTreeHostFactory (above) the
unique WindowTree instance was already created.

* services/ui/ws/window_tree_host_factory_registrar.cc|h:

  This class implements WindowTreeHostFactoryRegistrar class.
  It exposes a ::Register method, that:

    (a) Binds the mojom::WindowTreeHostFactoryRequest
    (b) Binds the mojom::WindowTreeRequest
    (c) Stores the mojom::WindowTreeClientPtr to call out
        WindowTreeClient later on.
    (d) A ws::WindowTree instance is also created here. It ensures
        single WindowTree and WindowTreeClient instances serving
        various WindowTreeHost instances.

  The goal of the WindowTreeHostFactoryRegistrar interface is
  to ensure a WindowTreeHostFactory::CreatePlatformWindow can not
  be called before WindowTreeHostFactory being properly set up.

* services/ui/ws/window_tree_host_factory.cc|h:

  Adds ::CreatePlatformWindow method so that it triggers the
  creation of per-outer-window ws::Display instances in external
  window mode.

TODO (in follow up CLs):

  1) Factor non-specific WindowManager specific bits out of
  ws::WindowManagerState, so that event dispatching code can be
  shared between internal and external window modes.

  2) Rename WindowManagerDisplayRoot since it is used in non-WindowManager
  path.

  3) Clean up mus_demo_external (launch instances in parallel?).

  4) Clean up WindowTreeClient::OnEmbed flow.

  5) Experiment with launching Chrome in external window mode.

BUG=666958

patch from issue 2712203002 at patchset 240001 (http://crrev.com/2712203002#ps240001)

Conflicts:
	services/ui/service.cc
	services/ui/service.h
	ui/aura/mus/window_tree_client.cc

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

In external window mode, it makes no sense to call
DisplayManager::OnDisplayUpdate when a ws::Display is
initialized.

First because ws::Display has not information about
display::Display instances. Second because ws::Display::display_
is solely to be used in internal window mode, as per the comment
in the header.

Conflicts:
	services/ui/ws/mus_ws_unittests_app_manifest.json
	services/ui/ws/window_server.h
	ui/aura/mus/window_tree_client.h

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

This CL makes the WindowTreeClient awaits on the WindowTree
connection to establish before it continues.

Before this, there was a mismatch between the values of
WindowTreeClient::client_id_ and the WindowTree::id_. The
reason was because the former was only updated when
WindowTreeClient::OnEmbed was called.

With the patch, we behave similarly to (m)ash, where it awaits for
the WindowTreeClient::OnConnect call, where the WTC::client_id_ is
set.

This fixes one of the blockers on using WindowManagerAccessPolicy
for both chrome/mus_demo and unittests.

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

This fixes a crash in touch handling.

Issue #100

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

Patch makes WindowTreeHostFactory an associated interface of WindowTree,
in external window mode.
This allows both interfaces to share the same mojo pipe, ensuring
ordering of messages.

This is important because during the creation of windows/ws::Display's,
WindowTreeHostFactory::CreatePlatformWindow messages concurs with
subsequent WindowTree method calls, causing non-deterministic crashes
in chrome/mus.

In summary, the patch:

- renames WindowTreeHostFactoryRegistrar to ExternalWindowTreeFactory.
- removes the use/logic of the WindowTreeHostFactoryRequest from the
  ::Registrar method.
- adds a WindowTree::GetWindowTreeHostFactory method that takes an
  associated interface request.
- adapts call sites accordingly.

In the end the new ExternalWindowTreeFactory flow works more similarly
to WindowTreeFactory's and WindowManagerWindowTreeFactory's.

Issue #161.

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

Avoid double initialization of WindowTreeHost: after
https://chromium-review.googlesource.com/c/606933 commit, the
chromium browser on Linux build with ozone has stopped to
start. It has always been observing a crash due to a DCHECK
in WindowTreeHost::InitCompositor(), which checked that
the compositor must not have a root_layer() set.

The reason of hitting the DCHECK is that the very first initialization
is always done during the browser start up:

6 0x7f4ff06c0981 views::DesktopNativeWidgetAura::InitNativeWidget()
7 0x7f4ff0682405 views::Widget::Init()
8 0x55e62a03742c BrowserFrame::InitBrowserFrame()
9 0x55e629d227e9 BrowserWindow::CreateBrowserWindow()
10 0x55e629b3d4e5 (anonymous namespace)::CreateBrowserWindow()
11 0x55e629b3cb79 Browser::Browser()
12 0x55e629b9b1b2 StartupBrowserCreatorImpl::OpenTabsInBrowser()
13 0x55e629b9cffa StartupBrowserCreatorImpl::RestoreOrCreateBrowser()
14 0x55e629b9a6a6 StartupBrowserCreatorImpl::ProcessLaunchUrlsUsingConsolidatedFlow()
15 0x55e629b99742 StartupBrowserCreatorImpl::Launch()
16 0x55e629b93a72 StartupBrowserCreator::LaunchBrowser()
17 0x55e629b929d4 StartupBrowserCreator::ProcessCmdLineImpl()
18 0x55e629b91102 StartupBrowserCreator::Start()
19 0x55e626f60fc7 ChromeBrowserMainParts::PreMainMessageLoopRunImpl()
20 0x55e626f5f8bc ChromeBrowserMainParts::PreMainMessageLoopRun()
21 0x7f4ff563c574 content::BrowserMainLoop::PreMainMessageLoopRun()

After this when WindowTreeClient::OnEmbed() is called,
we used to call window_tree_host->InitHost() second time and then
crash.

What is more, in order to mimic standart browser creation,
make WindowTreeDataExternal to call InitHost() before allowing
to calling to create an actual window.

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

Adapt to https://chromium-review.googlesource.com/c/chromium/src/+/617378.

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

Remove this secondary blocking Wait call [1], since it was
causing Mus to hang undeterministically.

Valid displays will be awaited in ScreenMus.

[1] https://github.com/Igalia/chromium/pull/129/

Issue #212