• Antonio Gomes's avatar
    c++ / mojo changes for 'external window mode' · 0ab13293
    Antonio Gomes authored
    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
    ::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
    * 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
      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.
    patch from issue 2712203002 at patchset 240001 (http://crrev.com/2712203002#ps240001)
    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
    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.
    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
    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
    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
Last commit
Last update
android Loading commit data...
app Loading commit data...
app_shim Loading commit data...
browser Loading commit data...
build Loading commit data...
child Loading commit data...
chrome_watcher Loading commit data...
common Loading commit data...
docs Loading commit data...
gpu Loading commit data...
install_static Loading commit data...
installer Loading commit data...
nacl Loading commit data...
profiling Loading commit data...
renderer Loading commit data...
service Loading commit data...
services Loading commit data...
test Loading commit data...
third_party Loading commit data...
tools Loading commit data...
utility Loading commit data...
BUILD.gn Loading commit data...
DEPS Loading commit data...
MAJOR_BRANCH_DATE Loading commit data...
OWNERS Loading commit data...
PRESUBMIT.py Loading commit data...
PRESUBMIT_test.py Loading commit data...
VERSION Loading commit data...
chrome_paks.gni Loading commit data...
chrome_repack_locales.gni Loading commit data...
process_version_rc_template.gni Loading commit data...
typemaps.gni Loading commit data...