Commit 0ab13293 authored by Committed by Santosh Mahto
c++ / mojo changes for 'external window mode'
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 .  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 , since it was causing Mus to hang undeterministically. Valid displays will be awaited in ScreenMus.  https://github.com/Igalia/chromium/pull/129/ Issue #212
Showing with 469 additions and 97 deletions