1. 06 Dec, 2017 1 commit
  2. 23 Nov, 2017 1 commit
    • Antonio Gomes's avatar
      Rework our "access policy" implementation · 6bd1e0fc
      Antonio Gomes authored
      Patch introduces a ExternalWindowAccessPolicy class,
      that allows us to run both chrome/mus and services_unittests
      using the same "access policy" instance.
      Previously, we were switching from a tweaked DefaultAccessPolicy
      use (chrome/mus) to WindowManagerAccessPolicy use (unit tests).
      Later we refactored out implementation to use the "manually
      created display" mode, and sticked with WindowManagerAccessPolicy
      At this time, we switch from using our own: ExternalWindowAccessPolicy.
      It inherits from WindowManagerAccessPolicy and reimplements the methods
      relevant for us (namely, ::CanSetWindowBounds).
      Issue #133
      Issue #149
      fixup! Rework our "access policy" implementation
      Set the proper access policy from WindowServer::CreateTreeForWindowManager,
      now that ExternalWindowTreeFactory uses it.
      Issue #266
  3. 22 Nov, 2017 3 commits
    • Antonio Gomes's avatar
      Add basic mouse events support · 5c8399fd
      Antonio Gomes authored
      This CL adds basic mouse events support. Events over overlapping
      areas of multiple Chrome windows is still broken, but should be
      fixed in a follow up CL.
    • 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
    • Antonio Gomes's avatar
      Allow ws to pass display::Display data to Aura/client · 015f3ed1
      Antonio Gomes authored
      Change ScreenManagerOzoneExternal to be able to send out display::Display
      updates via ws::UserDisplayManager (which will send the display::Display
      to the client).
      For this, patch extends OzonePlatform with a method that allows
      its instances (X11, Wayland, etc) to query the host system its displays
      data (resolution only for now).
      ScreenManagerOzoneExternal then calls to ws::DisplayManager, which calls to
      In order to allow ws::DisplayManager to get display::Display and not change
      ws::Display in external mode, a new hook was added: ::OnHostDisplaysReady.
      Wayland support will come in a fixup.
      Issue #43
        Contains fixup in ozone_platform_headless for fixing
      (TEMP) fixup! Allow ws to pass display::Display data to Aura/client
        Fix creating ui::Display after https://codereview.chromium.org/2829733002/
        is upstreamed
      fixup! Allow ws to pass display::Display data to Aura/client
      Use a non-zero value for FrameDecorationValues::normal_client_area_insets,
      so that the tabstrip has room to get drawn.
      The value '33' was picked up by mimic'ing ChromeOS's Chrome/Mash.
      Issue #56
      Issue #43
      fixup! Allow ws to pass display::Display data to Aura/client
      PR #50, reverted an initial hack added as part of the commit
      "Allow chrome launch with --mus parameter", but it left over one
      This commits removes the left over bit, but in the next rebase
      this should be squashed against "Allow chrome launch with --mus parameter"
      commit, not "Allow ws to pass display::Display data to Aura/client".
      fixup! Allow ws to pass display::Display data to Aura/client
      null-check the pointer before dereferencing it. nullptr is
      deliberately pass in sometimes.
      Issue #43
      fixup! fixup! Allow ws to pass display::Display data to Aura/client
      During the April/24 rebase, msisov@ hardcoded the ScreenManager creating
      in ws::service. This method adds a call to ws::Service::OnWillCreateTreeForWindowManager,
      similarly to how internal window mode does.
      fixup! Allow ws to pass display::Display data to Aura/client
      Implement OzonePlatformWayland::QueryHostDisplaysData. Note
      that by the time WaylandOutput is instantiated, the associated
      WaylandConnection object needs to be able to receive and process
      events, so that it can handle wl_output_listener hooks.
      Issue #43
      fixup! Allow ws to pass display::Display data to Aura/client
      Now that Mus runs as a thread within the Browser process, we can not
      install ScreenManagerOzoneExternal's Screen instance. Instead, it is
      only used internally to track displays (add, remove, modify).
      This fixes a crash at shutdown.
      PR #250
      fixup! Allow ws to pass display::Display data to Aura/client
      Stop early listen to events, when wl_output is installed.
      This call was causing us to enter the event loop earlier than we should,
      and occasional hangs at start up.
      Instead, when display/screen data is queried, we "ask" the server
      to close all pending requests associated with a given wl_display.
      Screen dimensions then can be queried.
      Issue #212
      fixup! Allow ws to pass display::Display data to Aura/client
      Fix unittests: after the change to WaylandConnection::Initialize, the
      unittests started to hang on startup, because the WaylandOutput::Geometry
      had always been empty.
      The fix is to create a MockOutput, which is a global wl object on the
      server side, with non-empty geometry, which will be set during initializtion
      The second fix is to modify WaylandConnectionTest::Output in such a way that
      it would not wait in a blocking run loop. At the moment, we have
      a wl_display_roundtrip run until WaylandOutput::Geometry is set instead.
  4. 14 Nov, 2017 35 commits