The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d30059398a5b1f1d09ad437c9f9def392c605790

commit d30059398a5b1f1d09ad437c9f9def392c605790
Author: tonikitoo <tonikitoo@igalia.com>
Date: Thu Feb 09 00:58:23 2017

Rename ScreeManagerOzone to ScreenManagerOzoneInternal

CL renames ScreeManagerOzone to ScreenManagerOzoneInternal,
and ScreeManagerStub to ScreenManagerStubInternal to reflect
their current 'internal window mode' purposes.

Eventually, we will have a ScreenManagerOzoneExternal class,
which should support 'external window mode' with Mus.

BUG= 666958 

Review-Url: https://codereview.chromium.org/2685003002
Cr-Commit-Position: refs/heads/master@{#449168}

[modify] https://crrev.com/d30059398a5b1f1d09ad437c9f9def392c605790/services/ui/display/BUILD.gn
[rename] https://crrev.com/d30059398a5b1f1d09ad437c9f9def392c605790/services/ui/display/screen_manager_ozone_internal.cc
[rename] https://crrev.com/d30059398a5b1f1d09ad437c9f9def392c605790/services/ui/display/screen_manager_ozone_internal.h
[rename] https://crrev.com/d30059398a5b1f1d09ad437c9f9def392c605790/services/ui/display/screen_manager_ozone_internal_unittests.cc
[rename] https://crrev.com/d30059398a5b1f1d09ad437c9f9def392c605790/services/ui/display/screen_manager_stub_internal.cc
[rename] https://crrev.com/d30059398a5b1f1d09ad437c9f9def392c605790/services/ui/display/screen_manager_stub_internal.h

Changing the bug title to reflect more our longer term plans for mus/external window mode.

I'll copy and paste my comment how about how external window mode could work with mus.

1. MusDemoExternal connects to service:ui via mojom::WindowTreeHostFactory. MusDemoExternal is not a WM and never connects via the mojom::WindowManager.
2. service:ui starts in external window mode. It got a connection from mojom::WindowTreeHostFactory so it knows it’s in external window mode.
3. Service:ui creates a ScreenManagerOzoneExternal. This never calls anything on the ScreenManagerDelegate because that will create a ws::Display. ScreenManager can’t create ws::Displays in external mode.
4. Service:ui creates a ws::Display for the top level Chrome window. This takes a bit of a different code path that is definitely all broken.
5. MusDemoExternal finishes the connection to the WindowTree for the top level Window.

The biggest challenge is that there are many assumptions in services/ui/ws/ that a mojom::WindowManager connection exists. There isn’t a WindowManager in external mode because the host operating system plays that role. Those assumptions need to be fixed so the window server will start and run.

I am pasting below pieces of the information spread around various CLs, that I consider relevant:

** kylechar commented on https://codereview.chromium.org/2622103004/#msg11:

The conversation for how external window mode could work with MusDemo is kind of
spread across multiple CLs, but here is an example for how I think it could
work.
1. MusDemoExternal connects to service:ui via mojom::WindowTreeHostFactory.
MusDemoExternal is not a WM and never connects via the mojom::WindowManager.
2. service:ui starts in external window mode. It got a connection from
mojom::WindowTreeHostFactory so it knows it’s in external window mode.
3. Service:ui creates a ScreenManagerOzoneExternal. This never calls anything on
the ScreenManagerDelegate because that will create a ws::Display. ScreenManager
can’t create ws::Displays in external mode.
4. Service:ui creates a ws::Display for the top level Chrome window. This takes
a bit of a different code path that is definitely all broken.
5. MusDemoExternal finishes the connection to the WindowTree for the top level
Window.


** kylechar wrote in https://codereview.chromium.org/2645093003/#msg15:

I don't think this is the right thing to do. ScreenManagerOzone is perhaps
poorly named and it should be ScreenManagerChromeOS or ScreenManagerInternal but
it's built for Chrome OS. It will only work for internal window mode and it
controls the size of root drawable surfaces. For external window mode
ScreenManager doesn't control the root drawable surfaces, so there isn't much /
any code overlap.

ScreenManagerOzone won't compile if target_os != "chromeos". I think you'll need
to write a different ScreenManager implementation for external window mode or
maybe you can use ScreenManagerStub for now. 

The bulk of the work to get external window mode working is the WS. Right now
each ws::Display corresponds to a root drawable surface. The ws::Display has a
ws::PlatformDisplay (which again isn't well named) which is basically what
allows you to draw to a surface, it owns the ui::PlatformWindow and
ws::FrameGenerator. The WS needs to be changed so that ws::Display doesn't own a
ws::PlatformDisplay. The top level Chrome ServerWindows need to own
ws::PlatformDisplay, which I guess means that a ServerWindow owns the
ws::PlatformDisplay in both external and internal window mode.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5a530bcea5b4fcadadb6fa6af191f91c880a06b1

commit 5a530bcea5b4fcadadb6fa6af191f91c880a06b1
Author: fwang <fwang@igalia.com>
Date: Thu Feb 09 18:30:05 2017

Refactor Mus demo to prepare support for multiple external windows

In order to demonstrate multiple external windows (with their own
spinnig square), the Mus demo must store information for each of the
window. This CL groups the relevant WindowTreeHost-specific data into
a separate class, so that it will be more convenient to handle
them. In particular, the initialization, cleanup and animation of
the data are moved into that class.

BUG= 666958 

Review-Url: https://codereview.chromium.org/2679213003
Cr-Commit-Position: refs/heads/master@{#449356}

[modify] https://crrev.com/5a530bcea5b4fcadadb6fa6af191f91c880a06b1/services/ui/demo/mus_demo.cc
[modify] https://crrev.com/5a530bcea5b4fcadadb6fa6af191f91c880a06b1/services/ui/demo/mus_demo.h

It's worth noting what I described in #5 is two different approaches. After talking with rjkroege offline, the people who met at Ozone wayland breakout of BlinkOn decided on the first approach. So that second approach is incorrect and shouldn't be followed.

Thanks kylechar@

thomasanderson@, I am assigning this bug to Frederic, who is working with me on getting external-window-mode capability to Mus.

Your CLs are off course still welcome here :-).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c2a0b99030720bb2b0727cedb82f6debbc9a1f12

commit c2a0b99030720bb2b0727cedb82f6debbc9a1f12
Author: fwang <fwang@igalia.com>
Date: Fri Feb 10 20:43:11 2017

Mus Demo: Reorganize functions in mus_demo.cc

In [1], some functions were moved from the MusDemo class to the
MusDemo::WindowTreeData class. Their bodies were however not moved
inside mus_demo.cc (in order to facilitate review). This is now done in
this CL and MusDemo::WindowTreeData member functions are grouped together
at the same location. At the same time, the body of the constructor is
actually moved to a separate Init function so that it can be used by
another constructor in a follow-up CL.

BUG= 666958 
R=rjkroege@chromium.org

[1] https://codereview.chromium.org/2679213003/

Review-Url: https://codereview.chromium.org/2688123002
Cr-Commit-Position: refs/heads/master@{#449725}

[modify] https://crrev.com/c2a0b99030720bb2b0727cedb82f6debbc9a1f12/services/ui/demo/mus_demo.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/01d9b79fa9fda1529d3c1d09ae1eb0f0d68140c7

commit 01d9b79fa9fda1529d3c1d09ae1eb0f0d68140c7
Author: fwang <fwang@igalia.com>
Date: Mon Feb 13 18:33:57 2017

Mus Demo: Code cleanup in MusDemo::WindowTreeData

This CL performs the following cleanup:

* The logging of the time past since the last frame drawing is removed.
* The root_window_ and bitmap_window_ members are removed since they
  can be accessed from the window_tree_host_. Actually, only the bitmap
  window is now handled outside the initialization function and a
  helper function is added to retrieve it.
* The destructor is removed since the cleanup is done when members are
  destroyed: The bitmap window is owned by its parent itself owned by
  WindowTreeData::window_tree_host_ and WindowTreeData::timer_
  is stopped in base::Timer::~Timer().
* Add missing DISALLOW_COPY_AND_ASSIGN to WindowTreeData.
* Use proper coordinates for the bitmap window operations.

BUG= 666958 
R=sky@chromium.org

Review-Url: https://codereview.chromium.org/2688013003
Cr-Commit-Position: refs/heads/master@{#450023}

[modify] https://crrev.com/01d9b79fa9fda1529d3c1d09ae1eb0f0d68140c7/services/ui/demo/mus_demo.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c50f6629b59e6e3e3087ca8dd3fb73518c4bf0dd

commit c50f6629b59e6e3e3087ca8dd3fb73518c4bf0dd
Author: fwang <fwang@igalia.com>
Date: Mon Feb 13 18:48:26 2017

Mus Demo: Add square size parameter to the WindowTreeData constructor

For a demonstration of multiple external windows it is interesting to
have different content drawn in order to distinguish the windows. This
is also useful to distinguish internal VS external mode. This CL adds a
parameter to the WindowTreeData constructor that can be used to specify
the square size in pixels.

BUG= 666958 
R=rjkroege@chromium.org

Review-Url: https://codereview.chromium.org/2688813003
Cr-Commit-Position: refs/heads/master@{#450030}

[modify] https://crrev.com/c50f6629b59e6e3e3087ca8dd3fb73518c4bf0dd/services/ui/demo/mus_demo.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5a9fe272cb758a4a60f251bd797144fa7c75e79f

commit 5a9fe272cb758a4a60f251bd797144fa7c75e79f
Author: tonikitoo <tonikitoo@igalia.com>
Date: Mon Feb 13 23:50:36 2017

Stub out ScreenManagerOzoneExternal

This is a step forward in order to have mus_demo
(//services/ui/demo/) running in "external window mode".

In external window mode, the need for a ScreenManager and
ScreenManagerDelegate (aka DisplayManager) is eased.
CL adds an stub'ed out implementation to be used on ozone/non-chromeos.

BUG= 666958 

Review-Url: https://codereview.chromium.org/2697693002
Cr-Commit-Position: refs/heads/master@{#450155}

[modify] https://crrev.com/5a9fe272cb758a4a60f251bd797144fa7c75e79f/services/ui/display/BUILD.gn
[add] https://crrev.com/5a9fe272cb758a4a60f251bd797144fa7c75e79f/services/ui/display/screen_manager_ozone_external.cc
[add] https://crrev.com/5a9fe272cb758a4a60f251bd797144fa7c75e79f/services/ui/display/screen_manager_ozone_external.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/da4637b0c789f6360dacdea216dd5316972862ee

commit da4637b0c789f6360dacdea216dd5316972862ee
Author: fwang <fwang@igalia.com>
Date: Wed Feb 15 17:01:16 2017

Mus Demo: Move definition of WindowTreeData into mus_demo.h

In follow-up CLs, MusDemo will be split into two derived classes
demonstrating external and internal modes. These classes will handle
instances of WindowTreeData and for that purpose this CL moves the
definition of WindowTreeData into separate files. We also adjust a bit
the Constructor/Init to help in future CLs.

BUG= 666958 
R=kylechar@chromium.org

Review-Url: https://codereview.chromium.org/2694843005
Cr-Commit-Position: refs/heads/master@{#450726}

[modify] https://crrev.com/da4637b0c789f6360dacdea216dd5316972862ee/services/ui/demo/BUILD.gn
[modify] https://crrev.com/da4637b0c789f6360dacdea216dd5316972862ee/services/ui/demo/mus_demo.cc
[modify] https://crrev.com/da4637b0c789f6360dacdea216dd5316972862ee/services/ui/demo/mus_demo.h
[add] https://crrev.com/da4637b0c789f6360dacdea216dd5316972862ee/services/ui/demo/window_tree_data.cc
[add] https://crrev.com/da4637b0c789f6360dacdea216dd5316972862ee/services/ui/demo/window_tree_data.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/03f2053328cb3ab19f5c5a0348cc3581576bbe49

commit 03f2053328cb3ab19f5c5a0348cc3581576bbe49
Author: bruthig <bruthig@chromium.org>
Date: Wed Feb 15 18:23:38 2017

Revert of Mus Demo: Move definition of WindowTreeData into separate files. (patchset #4 id:60001 of https://codereview.chromium.org/2694843005/ )

Reason for revert:
This change appears to have broken the compile step of the following build:

https://build.chromium.org/p/chromium/builders/Win%20x64/builds/8536

Original issue's description:
> Mus Demo: Move definition of WindowTreeData into mus_demo.h
>
> In follow-up CLs, MusDemo will be split into two derived classes
> demonstrating external and internal modes. These classes will handle
> instances of WindowTreeData and for that purpose this CL moves the
> definition of WindowTreeData into separate files. We also adjust a bit
> the Constructor/Init to help in future CLs.
>
> BUG= 666958 
> R=kylechar@chromium.org
>
> Review-Url: https://codereview.chromium.org/2694843005
> Cr-Commit-Position: refs/heads/master@{#450726}
> Committed: https://chromium.googlesource.com/chromium/src/+/da4637b0c789f6360dacdea216dd5316972862ee

TBR=kylechar@chromium.org,fwang@igalia.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 666958 

Review-Url: https://codereview.chromium.org/2694413003
Cr-Commit-Position: refs/heads/master@{#450742}

[modify] https://crrev.com/03f2053328cb3ab19f5c5a0348cc3581576bbe49/services/ui/demo/BUILD.gn
[modify] https://crrev.com/03f2053328cb3ab19f5c5a0348cc3581576bbe49/services/ui/demo/mus_demo.cc
[modify] https://crrev.com/03f2053328cb3ab19f5c5a0348cc3581576bbe49/services/ui/demo/mus_demo.h
[delete] https://crrev.com/064a292ce35b28592529c5bded26f905d65833a9/services/ui/demo/window_tree_data.cc
[delete] https://crrev.com/064a292ce35b28592529c5bded26f905d65833a9/services/ui/demo/window_tree_data.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/600a1b10bce210bcd850268024a2413a0ee0d0fa

commit 600a1b10bce210bcd850268024a2413a0ee0d0fa
Author: fwang <fwang@igalia.com>
Date: Thu Feb 16 13:40:28 2017

Reland Mus Demo: Move definition of WindowTreeData into separate files

Reason for revert:
Unfortunate final s/int/unsigned/ causing Windows build errors [1].
Relanding it without that final change.

Original issue's description:
> Mus Demo: Move definition of WindowTreeData into mus_demo.h
>
> In follow-up CLs, MusDemo will be split into two derived classes
> demonstrating external and internal modes. These classes will handle
> instances of WindowTreeData and for that purpose this CL moves the
> definition of WindowTreeData into separate files. We also adjust a bit
> the Constructor/Init to help in future CLs.

[1] https://codereview.chromium.org/2694843005/#msg31

BUG= 666958 
R=kylechar@chromium.org

Review-Url: https://codereview.chromium.org/2697013004
Cr-Commit-Position: refs/heads/master@{#450945}

[modify] https://crrev.com/600a1b10bce210bcd850268024a2413a0ee0d0fa/services/ui/demo/BUILD.gn
[modify] https://crrev.com/600a1b10bce210bcd850268024a2413a0ee0d0fa/services/ui/demo/mus_demo.cc
[modify] https://crrev.com/600a1b10bce210bcd850268024a2413a0ee0d0fa/services/ui/demo/mus_demo.h
[add] https://crrev.com/600a1b10bce210bcd850268024a2413a0ee0d0fa/services/ui/demo/window_tree_data.cc
[add] https://crrev.com/600a1b10bce210bcd850268024a2413a0ee0d0fa/services/ui/demo/window_tree_data.h

Just a quick overview of the plan right now (still WIP):

Move internal in a derived class: https://codereview.chromium.org/2693923004/
External mode (single window): https://codereview.chromium.org/2622103004/
External mode (multiple windows): https://codereview.chromium.org/2700493005/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/88bda6e478572197c7c1dcf6bc6fb0b7b3f1e586

commit 88bda6e478572197c7c1dcf6bc6fb0b7b3f1e586
Author: fwang <fwang@igalia.com>
Date: Sat Feb 18 17:32:12 2017

Mus Demo: Extract code specific to internal mode into a separate class

This CL extracts code from MusDemo into a derived class MusDemoInternal
demonstrating internal mode. In a follow-up CL, another derived class
MusDemoExternal will demonstrate external mode and will be used for
non-ChromeOS Ozone builds. Some helper functions are added to try and
have consistency between internal/external implementations.

BUG= 666958 
R=kylechar@chromium.org

Review-Url: https://codereview.chromium.org/2693923004
Cr-Commit-Position: refs/heads/master@{#451472}

[modify] https://crrev.com/88bda6e478572197c7c1dcf6bc6fb0b7b3f1e586/services/ui/demo/BUILD.gn
[modify] https://crrev.com/88bda6e478572197c7c1dcf6bc6fb0b7b3f1e586/services/ui/demo/main.cc
[modify] https://crrev.com/88bda6e478572197c7c1dcf6bc6fb0b7b3f1e586/services/ui/demo/mus_demo.cc
[modify] https://crrev.com/88bda6e478572197c7c1dcf6bc6fb0b7b3f1e586/services/ui/demo/mus_demo.h
[add] https://crrev.com/88bda6e478572197c7c1dcf6bc6fb0b7b3f1e586/services/ui/demo/mus_demo_internal.cc
[add] https://crrev.com/88bda6e478572197c7c1dcf6bc6fb0b7b3f1e586/services/ui/demo/mus_demo_internal.h

(Comment #19 had some incomplete sentences. I deleted it and re-posted it below)

In parallel to the work Frederic is doing on MusDemo, I am working out the following plan (as per our understanding of sky@ and kylechar@ advises):

-------------------
UI side:

1) Change WindowTreeHostFactory definition as follows

interface WindowTreeHostFactory {
-  // Creates a new WindowTreeHost. |tree_client| is queried for the
-  // WindowManager.
-   CreateWindowTreeHost(WindowTreeHost& window_tree_host,
-                       WindowTreeClient tree_client);

+  Register(WindowTree& tree_request, WindowTreeClient client);
+  CreateWindowTreeHost(WindowTreeHost& window_tree_host);
}

This way, we can have single instances of ws::WindowTree and mojom::WindowTreeClientPtr, being able to create various WindowTreeHost's.

The instantiation of the ws::WindowTree and mojom::WindowTreeClientPtr would happen in ::Register, whereas ::CreateWindowTreeHost would create new ws::Displays (ws::PlatformDisplays -> ui::PlatformWindow).

WindowTreeClientPtr::OnEmbed would be called for every ws::Display (or 'window tree host' request) creation, passing 'nullptr' as mojom::WindowTreePtr (3rd argument).
This is because ui::WindowTreeClient already holds a unique mojom::WindowTreePtr. 


Aura side:

- Add WindowTreeClient::ConnectViaWindowTreeHostFactory method.

This will call (via mojo API) WindowTreeHostFactory::Register.

- Add a WindowTreeClient::CreateHost (to be agreed on the name?), where WindowTreeHostFactory::CreateWindowTreeHost will be called (via mojo API).

- Change WindowTreeClient::OnEmbed so that it can receive an null'ed out mojom::WindowTreePtr argument.


Mus demo

Change mus-demo exiting external window mode support, so that it makes the appropriate mojo calls for ui::WindowTreeClient, resulting in a simpler implementation.
-------------------

Comments welcome. Impl work is ongoing..

+sky@ in case he as feedback on the plan described in comment #20.

I recommend putting Register and Create on separate interfaces, where the interface containing Create is obtained in Register. That way you don't have the possibility of Create being called before Register.

Also, avoid using WindowTreeHost in these names. That name is too confusing given we have aura::WindowTreeHost.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597

commit 12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597
Author: fwang <fwang@igalia.com>
Date: Wed Feb 22 08:12:34 2017

Mus Demo: Demonstrate external window mode

Previously the only user of mus was ChromeOS, and so Chrome currently
creates all toplevel windows as children of an ash-managed root window.
In this sense, all created windows are 'internal' to this virtual root.
However, as desktop Linux also transitions to using Mus, it is necessary
to support 'external' window mode where toplevel windows are created as
native (x11, wayland, ...) windows.

This CL adjusts the Mus Demo so that non-ChromeOS Ozone platforms work
in external mode. For now, only a single external window is created by
Mus Demo. Supporting multiple external windows will require some code
refactoring in WindowTreeHostFactory that will be handled in a
follow-up CL [1].

The CL also disables an assertion for these non-ChromeOS Ozone platforms
until display & screen managers are refactored to remove assumptions
specific to internal mode [2].

[1] https://codereview.chromium.org/2700493005
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=693081

BUG= 666958 
TEST=./out/LinuxOzoneX11/mash --service=mus_demo --ozone-platform=x11 or ./out/LinuxOzoneX11/mus_demo_unittests --ozone-platform=x11

Review-Url: https://codereview.chromium.org/2622103004
Cr-Commit-Position: refs/heads/master@{#451922}

[modify] https://crrev.com/12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597/services/ui/demo/BUILD.gn
[add] https://crrev.com/12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597/services/ui/demo/main_external.cc
[rename] https://crrev.com/12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597/services/ui/demo/main_internal.cc
[modify] https://crrev.com/12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597/services/ui/demo/manifest.json
[modify] https://crrev.com/12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597/services/ui/demo/mus_demo.cc
[modify] https://crrev.com/12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597/services/ui/demo/mus_demo.h
[add] https://crrev.com/12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597/services/ui/demo/mus_demo_external.cc
[add] https://crrev.com/12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597/services/ui/demo/mus_demo_external.h
[modify] https://crrev.com/12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597/services/ui/demo/mus_demo_internal.cc
[modify] https://crrev.com/12d9a31ee89cb70348fd7c0bdc8d26f6ddebf597/services/ui/demo/mus_demo_internal.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/84358c00a81eab2e2ccc5485fbfe44ffc50307dc

commit 84358c00a81eab2e2ccc5485fbfe44ffc50307dc
Author: fwang <fwang@igalia.com>
Date: Fri Feb 24 22:51:37 2017

Mus Demo: Refactor code to prepare multiple windows in external mode

Support for external mode in Mus Demo was added in [1]. However, the
Mus Demo code is currently designed to work with a single
WindowTreeData. This CL refactors the code to be able to handle a
list of WindowTreeDatas instead. Actual support for multiple windows
will be handled in follow-up CLs.

BUG= 666958 

[1] https://codereview.chromium.org/2622103004/

Review-Url: https://codereview.chromium.org/2700493005
Cr-Commit-Position: refs/heads/master@{#452971}

[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo.cc
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo.h
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo_external.cc
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo_external.h
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo_internal.cc
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo_internal.h
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/window_tree_data.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/84358c00a81eab2e2ccc5485fbfe44ffc50307dc

commit 84358c00a81eab2e2ccc5485fbfe44ffc50307dc
Author: fwang <fwang@igalia.com>
Date: Fri Feb 24 22:51:37 2017

Mus Demo: Refactor code to prepare multiple windows in external mode

Support for external mode in Mus Demo was added in [1]. However, the
Mus Demo code is currently designed to work with a single
WindowTreeData. This CL refactors the code to be able to handle a
list of WindowTreeDatas instead. Actual support for multiple windows
will be handled in follow-up CLs.

BUG= 666958 

[1] https://codereview.chromium.org/2622103004/

Review-Url: https://codereview.chromium.org/2700493005
Cr-Commit-Position: refs/heads/master@{#452971}

[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo.cc
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo.h
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo_external.cc
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo_external.h
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo_internal.cc
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/mus_demo_internal.h
[modify] https://crrev.com/84358c00a81eab2e2ccc5485fbfe44ffc50307dc/services/ui/demo/window_tree_data.h

sky, kylechar: hi!

I am making progresses on the window external mode changes (server / client sides) - see the WIP CL in https://codereview.chromium.org/2712203002/ for more details.

In practice, the CL allows one to launch 'mus_demo_external' with various external windows, each containing its own spinning square - see attached picture.

On this set up, on the server we have one ws::WindowTree instance; on client, one ui::WindowTreeClient instance, servicing zero or more aura::WindowTreeHost's

Also, on this CL:

- WindowTreeHostFactoryRegistrar c++/mojo interface is added/implemented. As per your comment #22, this avoids the possibility of ::Create being called before ::Register.
See WindowTreeClient::ConnectViaWindowTreeHostFactory in https://codereview.chromium.org/2712203002/diff/20001/ui/aura/mus/window_tree_client.cc .

Called on the client side, WindowTreeHostFactoryRegistrar::Register creates  WindowTreeHostFactory and ws::WindowTree instances on the server side, and makes  Mojo handles WindowTreeHostFactory and WindowTree available on the client side.

- WindowTreeHostFactory::Create calls trigger ws::Display creations, which ends up calling back WindowTreeClient::OnEmbed, passing a nullptr as mojom::WindowTreePtr. Basically, WindowTreeClient::tree_ has already been created when ::Register was called above) - as per your suggestion in https://codereview.chromium.org/2622103004/#msg5

The open question today is:

- When setting up ws::Display instances WindowTree::window_manager_internal and WindowTree::window_manager_state_ are created via WindowTree::ConfigureWindowManager.

Are these objects needed at all in external window mode? 
If not, there is lots of logic that assume WindowTree::window_manager_state_ is always non-null that would need to be changed.

Deleted: Screenshot from 2017-02-27 01-28-47.png 79.9 KB

	Screenshot from 2017-02-27 01-28-47.png 79.9 KB View Download

WindowManagerState has a specific meaning that there is a WindowManager. This doesn't make sense in external mode. That said, there is some logic and state in WindowManagerState that is useful for both. For example, event dispatch should be the same. We'll likely need to refactor parts that are useful for both into standalone classes. I'm being a bit hand wavy here. I would need to spend time analyzing the needs of the two to come up with a concrete plan.

Just for your information, I finally got a chance to test Antonio's patch and I made a short video of Mus Demo with 5 "external mode" windows on Ozone/Wayland: https://vimeo.com/206391176

Also, I checked that my extension of mus_demo_unittests to check multiple windows worked as expected (https://codereview.chromium.org/2715533005/).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7dac3c6c0969d2c407213199691841e29baf3979

commit 7dac3c6c0969d2c407213199691841e29baf3979
Author: fwang <fwang@igalia.com>
Date: Thu Mar 09 23:45:38 2017

Disable unit tests for Window Manager Client in external window mode

After [1], no default display is created at the startup of the window
server, making the following mus_ws_unitests hang:

  WindowServerTest.OnWindowHierarchyChangedIncludesTransientParent
  WindowServerTest.RootWindow
  WindowServerTest.Embed
  WindowServerTest.EmbeddedDoesntSeeChild
  WindowServerTest.SetBounds
  WindowServerTest.SetBoundsSecurity
  WindowServerTest.DestroySecurity
  WindowServerTest.MultiRoots
  WindowServerTest.Reorder
  WindowServerTest.Visible
  WindowServerTest.EmbedFailsWithChildren
  WindowServerTest.WindowServerDestroyedAfterRootObserver
  WindowServerTest.ClientAreaChanged
  WindowServerTest.EstablishConnectionViaFactory

The issue is that WindowServerTestBase::SetUp is designed to wait
until OnWmNewDisplay is called to be sure that a display (and root)
is available, which never happens in external window mode.

The above tests check WindowManagerClient and this class is not needed
in external mode since the host system is always the window manager.
Hence this CL disables these tests in external window mode, making
mus_ws_unitests pass again on the corresponding platforms.

[1] https://codereview.chromium.org/2697693002/

BUG= 666958 

Review-Url: https://codereview.chromium.org/2740123002
Cr-Commit-Position: refs/heads/master@{#455902}

[modify] https://crrev.com/7dac3c6c0969d2c407213199691841e29baf3979/services/ui/ws/BUILD.gn

Update: on top of the latest patchset in https://codereview.chromium.org/2712203002/ , was able to launch Chrome/Mus (no ash at all) with both X11 and Wayland ozone backends.

See screenshots attached.

Deleted: Screenshot from 2017-03-11 01-45-25.png 136 KB

	Screenshot from 2017-03-11 01-45-25.png 136 KB View Download

Deleted: Screenshot from 2017-03-11 16-23-00.png 84.5 KB

	Screenshot from 2017-03-11 16-23-00.png 84.5 KB View Download

Just want to say, that is great progress. :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5217bf718aa6da446b8acee61341b1f4ceab2248

commit 5217bf718aa6da446b8acee61341b1f4ceab2248
Author: fwang <fwang@igalia.com>
Date: Wed Mar 15 23:59:21 2017

Run Mus Demo and WS tests on Ozone Linux bot

For the related changes on chromium/tools/build, see
https://chromium-review.googlesource.com/c/452481/

BUG= 666958 ,700309

Review-Url: https://codereview.chromium.org/2739183002
Cr-Commit-Position: refs/heads/master@{#457270}

[modify] https://crrev.com/5217bf718aa6da446b8acee61341b1f4ceab2248/testing/buildbot/chromium.fyi.json
[modify] https://crrev.com/5217bf718aa6da446b8acee61341b1f4ceab2248/tools/mb/mb_config.pyl

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/aea527346d04c035ab38f14e0c3df0647c32230d

commit aea527346d04c035ab38f14e0c3df0647c32230d
Author: msisov <msisov@igalia.com>
Date: Tue Mar 21 08:08:08 2017

Use xvfb for the ozone linux tests

This is needed to fix
linux_chromium_ozone_compile_only_ng to run tests with x11

BUG= 666958 

Review-Url: https://codereview.chromium.org/2764483002
Cr-Commit-Position: refs/heads/master@{#458349}

[modify] https://crrev.com/aea527346d04c035ab38f14e0c3df0647c32230d/tools/mb/mb.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9ca8fc91927b335661ab095f925b1337486e64d0

commit 9ca8fc91927b335661ab095f925b1337486e64d0
Author: msisov <msisov@igalia.com>
Date: Tue Mar 21 13:24:59 2017

Fix destruction order in mus_demo

Problem:
Unique pointers are deleted from the bottom to the upwards as they are
defined in a class definition. Before this CL, WindowTreeClient was
destroyed after WNState had its destructor called, which led to segfault.

Solution:
WindowTreeClient must be deleted before Env and WNState, otherwise signal 11 occurs.
It happens because Env and WNState are singletons, which are owned by
MusDemo. Once WindowTreeClient goes into its destructor, it uses them to
remove itself as an observer.

This fix is mainly aimed for
https://build.chromium.org/p/chromium.fyi/builders/Ozone%20Linux

Call stack-

Received signal 11 SEGV_MAPERR 000000000000
#0 0x7f501a7b83fb base::debug::StackTrace::StackTrace()
#1 0x7f501a7b6a8c base::debug::StackTrace::StackTrace()
#2 0x7f501a7b7f0f base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7f501ac3e390 <unknown>
#4 0x7f50179b46fb aura::WindowTreeClient::~WindowTreeClient()
#5 0x7f50179b4d69 aura::WindowTreeClient::~WindowTreeClient()
#6 0x000000431f9f std::default_delete<>::operator()()
#7 0x00000043198c std::unique_ptr<>::reset()
#8 0x000000430b59 std::unique_ptr<>::~unique_ptr()
#9 0x00000042f85c ui::demo::MusDemo::~MusDemo()
#10 0x00000043852f ui::demo::MusDemoExternal::~MusDemoExternal()
#11 0x000000438579 ui::demo::MusDemoExternal::~MusDemoExternal()
#12 0x000000431f9f std::default_delete<>::operator()()
#13 0x00000063080c std::unique_ptr<>::reset()
#14 0x00000062ece9 std::unique_ptr<>::~unique_ptr()
#15 0x00000062db7b service_manager::ServiceContext::~ServiceContext()
#16 0x00000062dbc9 service_manager::ServiceContext::~ServiceContext()

BUG= 666958 

Review-Url: https://codereview.chromium.org/2764433002
Cr-Commit-Position: refs/heads/master@{#458388}

[modify] https://crrev.com/9ca8fc91927b335661ab095f925b1337486e64d0/services/ui/demo/mus_demo.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f47783859bd6c4b4c363a1a4131c97c0abbaba98

commit f47783859bd6c4b4c363a1a4131c97c0abbaba98
Author: msisov <msisov@igalia.com>
Date: Wed Apr 12 09:06:37 2017

Add chrome compile target to Ozone Linux bot

Make bot not only run tests, but compile chrome as well to make sure
everything is in shape.

BUG= 666958 , 700309

Review-Url: https://codereview.chromium.org/2811853003
Cr-Commit-Position: refs/heads/master@{#463970}

[modify] https://crrev.com/f47783859bd6c4b4c363a1a4131c97c0abbaba98/testing/buildbot/chromium.fyi.json

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e293efc74b2050a2eb73e5d17009a59a3d57dc51

commit e293efc74b2050a2eb73e5d17009a59a3d57dc51
Author: msisov <msisov@igalia.com>
Date: Wed Jun 28 23:44:20 2017

Decouple X11WindowEventFilter into WindowEventFilter parent class.

This CL decouples X11WindowEventFilter into two classes: WindowEventFilter
and X11WindowEventFilter. X11WindowEventFilter would inherit from WindowEventFilter
and  continued instantiated/used  by stock Chrome/Chromium Linux/X11 builds,
as it is today, so there would be no functionality change here.

However, on the other side, downstream forks of Chromium could benefit from
the window system agnostic parts of the implementation, in the newly added
WindowEventFilter class. For instance, the Chromium Ozone/Mus implementation in
[1] would greatly benefit from it in other to provide resize and window dragging
functionalities.

FWIW, Ozone backends like X11 and Wayland already work with it downstream.

BUG= 666958 

Review-Url: https://codereview.chromium.org/2948553002
Cr-Commit-Position: refs/heads/master@{#483200}

[modify] https://crrev.com/e293efc74b2050a2eb73e5d17009a59a3d57dc51/ui/views/BUILD.gn
[modify] https://crrev.com/e293efc74b2050a2eb73e5d17009a59a3d57dc51/ui/views/widget/desktop_aura/OWNERS
[add] https://crrev.com/e293efc74b2050a2eb73e5d17009a59a3d57dc51/ui/views/widget/desktop_aura/window_event_filter.cc
[add] https://crrev.com/e293efc74b2050a2eb73e5d17009a59a3d57dc51/ui/views/widget/desktop_aura/window_event_filter.h
[modify] https://crrev.com/e293efc74b2050a2eb73e5d17009a59a3d57dc51/ui/views/widget/desktop_aura/x11_window_event_filter.cc
[modify] https://crrev.com/e293efc74b2050a2eb73e5d17009a59a3d57dc51/ui/views/widget/desktop_aura/x11_window_event_filter.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bc3da7549bc8fe686fd286de0c12a2c144c9aad9

commit bc3da7549bc8fe686fd286de0c12a2c144c9aad9
Author: Maksim Sisov <msisov@igalia.com>
Date: Mon Sep 18 09:50:45 2017

[ozone/wayland] Add xdg_v6 support

This commit adds an xdg_v6 support.
Both ChromeOS and Linux builds will use that.

The way it is done is following:

WaylandWindow doesn't know now about the shell version used.
It uses XDGShellObjectsFactory now to construct xdg_surfaces (and
xdg_popups in the future). The decision on what version of shell to use
is based on the shell version, which WaylandConnection has.

XDGShellObjectsFactory creates an XdgSurfaceWrapper object, which is
inherited by XdgSurfaceWrapperV5 or XdgSurfaceWrapperV6 objects.
Shell version specific interface implementation is hidden there.

This solution should allow to add more shells in the future with as
minimal changes as possible.

The FakeServer is modified in such a way that FakeServer::Start() takes
a shell version number passed by gtest object and instantiates requested
shell version. As soon as the connection is established, tests start to
run.

BUG= 666958 , 578890

Change-Id: Iba239cb87db88b0779d7221a07bef5de730a47bd
Reviewed-on: https://chromium-review.googlesource.com/666959
Commit-Queue: Maksim Sisov <msisov@igalia.com>
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Cr-Commit-Position: refs/heads/master@{#502544}
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/BUILD.gn
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/fake_server.cc
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/fake_server.h
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_connection.cc
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_connection.h
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_connection_unittest.cc
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_keyboard_unittest.cc
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_object.cc
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_object.h
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_pointer_unittest.cc
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_surface_factory_unittest.cc
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_test.cc
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_test.h
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_window.cc
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_window.h
[modify] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/wayland_window_unittest.cc
[add] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/xdg_surface_wrapper.h
[add] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/xdg_surface_wrapper_v5.cc
[add] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/xdg_surface_wrapper_v5.h
[add] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/xdg_surface_wrapper_v6.cc
[add] https://crrev.com/bc3da7549bc8fe686fd286de0c12a2c144c9aad9/ui/ozone/platform/wayland/xdg_surface_wrapper_v6.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a5a34d53527e8768d38059cd0db30a75d252ecec

commit a5a34d53527e8768d38059cd0db30a75d252ecec
Author: Maksim Sisov <msisov@igalia.com>
Date: Tue Nov 14 15:00:32 2017

[ozone] Use word *Fullscreen instead of *FullScreen.

This CL doesn't bring any functionality changes. It just aligns
the *Fullscreen word with other code around chromium.

TBR=rjkroege@chromium.org

Bug:  666958 
Change-Id: I8c3937a5221641750846738c93f46496c00551b8
Reviewed-on: https://chromium-review.googlesource.com/768741
Commit-Queue: Maksim Sisov <msisov@igalia.com>
Reviewed-by: Antonio Gomes <tonikitoo@igalia.com>
Cr-Commit-Position: refs/heads/master@{#516301}
[modify] https://crrev.com/a5a34d53527e8768d38059cd0db30a75d252ecec/ui/ozone/platform/wayland/xdg_surface_wrapper.h
[modify] https://crrev.com/a5a34d53527e8768d38059cd0db30a75d252ecec/ui/ozone/platform/wayland/xdg_surface_wrapper_v5.cc
[modify] https://crrev.com/a5a34d53527e8768d38059cd0db30a75d252ecec/ui/ozone/platform/wayland/xdg_surface_wrapper_v5.h
[modify] https://crrev.com/a5a34d53527e8768d38059cd0db30a75d252ecec/ui/ozone/platform/wayland/xdg_surface_wrapper_v6.cc
[modify] https://crrev.com/a5a34d53527e8768d38059cd0db30a75d252ecec/ui/ozone/platform/wayland/xdg_surface_wrapper_v6.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/68430fe4de6f345a80d58a0c579687721f2dd623

commit 68430fe4de6f345a80d58a0c579687721f2dd623
Author: Antonio Gomes <tonikitoo@igalia.com>
Date: Tue Nov 14 18:11:57 2017

Modernize mus_demo_external impl

This switches MusDemoExternal implementation to make use of
newly added WindowTreeClient::ConnectViaWindowTreeHostFactory API.

It allows us to remove some class parameters of WindowTreeDataExternal

BUG= 666958 

Change-Id: I12cb8e63d5bcd0c9484811b7cb09e0e546f866cb
Reviewed-on: https://chromium-review.googlesource.com/768987
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Cr-Commit-Position: refs/heads/master@{#516359}
[modify] https://crrev.com/68430fe4de6f345a80d58a0c579687721f2dd623/services/ui/demo/mus_demo.cc
[modify] https://crrev.com/68430fe4de6f345a80d58a0c579687721f2dd623/services/ui/demo/mus_demo_external.cc
[modify] https://crrev.com/68430fe4de6f345a80d58a0c579687721f2dd623/services/ui/demo/mus_demo_external.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/213ca3788ad79bab9e0894ff4f159cd7a4ac8909

commit 213ca3788ad79bab9e0894ff4f159cd7a4ac8909
Author: Maksim Sisov <msisov@igalia.com>
Date: Wed Nov 15 08:36:44 2017

[X11/Ozone X11] Share x11_pointer_grab helper methods with ozone.

This CL moves x11_pointer_grab.cc|h from ui/views/widget to
ui/base/x. There is no functionality change, but it allows
ozone/x11 (ui/platform_window/x11 code) to make use of these
helper methods too. Ozone/x11 changes will be sent as a
follow-up cl.

Bug:  666958 
Change-Id: Ib36fa4731612eafe6f95ddae9c84a20e388b9d14
Reviewed-on: https://chromium-review.googlesource.com/768709
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Maksim Sisov <msisov@igalia.com>
Cr-Commit-Position: refs/heads/master@{#516640}
[modify] https://crrev.com/213ca3788ad79bab9e0894ff4f159cd7a4ac8909/ui/base/x/BUILD.gn
[rename] https://crrev.com/213ca3788ad79bab9e0894ff4f159cd7a4ac8909/ui/base/x/x11_pointer_grab.cc
[add] https://crrev.com/213ca3788ad79bab9e0894ff4f159cd7a4ac8909/ui/base/x/x11_pointer_grab.h
[modify] https://crrev.com/213ca3788ad79bab9e0894ff4f159cd7a4ac8909/ui/views/BUILD.gn
[modify] https://crrev.com/213ca3788ad79bab9e0894ff4f159cd7a4ac8909/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[delete] https://crrev.com/c367d4b58771cad1af5cd0e910a4f12798a748a8/ui/views/widget/desktop_aura/x11_pointer_grab.h
[modify] https://crrev.com/213ca3788ad79bab9e0894ff4f159cd7a4ac8909/ui/views/widget/desktop_aura/x11_whole_screen_move_loop.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/587d6298cc4ccceef67999b466dc36adb80ca2fe

commit 587d6298cc4ccceef67999b466dc36adb80ca2fe
Author: Antonio Gomes <tonikitoo@igalia.com>
Date: Thu Nov 16 13:25:12 2017

Split window_tree_host.mojom into smaller interfaces

This CL splits window_tree_host.mojom, separating WindowTreeHostFactory
interface declaration into its own mojom file.

In practice, there is no behavior change at all, but the separation makes
it easier for downstreamers to having a Mojo interface sibling of
WindowTreeHostFactory (for instance, in case of external window mode,
there is a ExternalWindowTreeHostFactory, which has a different API).

BUG= 666958 

Change-Id: I664f9ac3895612b53c6a4b1cfc85785554fe9bab
Reviewed-on: https://chromium-review.googlesource.com/767527
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Maksim Sisov <msisov@igalia.com>
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Cr-Commit-Position: refs/heads/master@{#517070}
[modify] https://crrev.com/587d6298cc4ccceef67999b466dc36adb80ca2fe/services/ui/demo/mus_demo_external.h
[modify] https://crrev.com/587d6298cc4ccceef67999b466dc36adb80ca2fe/services/ui/public/interfaces/BUILD.gn
[modify] https://crrev.com/587d6298cc4ccceef67999b466dc36adb80ca2fe/services/ui/public/interfaces/window_tree_host.mojom
[add] https://crrev.com/587d6298cc4ccceef67999b466dc36adb80ca2fe/services/ui/public/interfaces/window_tree_host_factory.mojom
[modify] https://crrev.com/587d6298cc4ccceef67999b466dc36adb80ca2fe/services/ui/service.h
[modify] https://crrev.com/587d6298cc4ccceef67999b466dc36adb80ca2fe/services/ui/ws/display_binding.h
[modify] https://crrev.com/587d6298cc4ccceef67999b466dc36adb80ca2fe/services/ui/ws/window_tree_client_unittest.cc
[modify] https://crrev.com/587d6298cc4ccceef67999b466dc36adb80ca2fe/services/ui/ws/window_tree_host_factory.h
[modify] https://crrev.com/587d6298cc4ccceef67999b466dc36adb80ca2fe/ui/aura/mus/window_tree_client.cc

I recently tried --ozone-platform=x11 (Ubuntu 16.04) and --ozone-platform=wayland (latest Weston) on Desktop, it works pretty well with --mus and --mash, nice!
How far are you from supporting external-window-mode ?

Should this bug be marked as blocking crbug.com/578890 ?

(Though there is currently an issue with html5 video, see https://chromium-review.googlesource.com/c/chromium/src/+/776794 )

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bfa4c5b36c67068f8f7d99f36c0264ecac53dc6f

commit bfa4c5b36c67068f8f7d99f36c0264ecac53dc6f
Author: Antonio Gomes <tonikitoo@igalia.com>
Date: Mon Nov 27 21:27:12 2017

[ozone/wayland] Emit ET_MOUSE_EXITED upon cursor leave

This is important for supporting Aura use cases that relies on
ET_MOUSE_EXITED events being fired when mouse pointer leaves a
say Chrome window.

For instance, it fixes common use cases like 'hiding a tooltip
window when cursor leaves the browser window' in external window mode,
similarly to what stock chrome does.

BUG= 666958 

Change-Id: I8077fec47fbd09277928ef20adbbf2a12af55e4a
Reviewed-on: https://chromium-review.googlesource.com/791275
Reviewed-by: Michael Spang <spang@chromium.org>
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Cr-Commit-Position: refs/heads/master@{#519410}
[modify] https://crrev.com/bfa4c5b36c67068f8f7d99f36c0264ecac53dc6f/ui/ozone/platform/wayland/wayland_pointer.cc
[modify] https://crrev.com/bfa4c5b36c67068f8f7d99f36c0264ecac53dc6f/ui/ozone/platform/wayland/wayland_pointer_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bcfb895bd39c421db37531d48accf340b4c0440f

commit bcfb895bd39c421db37531d48accf340b4c0440f
Author: Antonio Gomes <tonikitoo@igalia.com>
Date: Tue Nov 28 03:20:42 2017

[ozone/x11] Map X's LeaveNotify to ET_MOUSE_EXITED

Ozone/X11 does not support use cases that rely on aura's
ET_MOUSE_EXITED event. This is because X's LeaveNotify events
are being translated to ET_MOUSE_MOVED, instead.

This differs, for instance, from stock chrome/x11, where the
translation happens in ui::EventTypeFromXEvent
(ui/events/x/events_x_utils.cc).

CL aligns both chrome/x11 and ozone/x11 behaviors, by changing
::TranslateXEventToEvent to call ::EventTypeFromXEvent.
As a result EnterNotify keeps being translated to ET_MOUSE_MOVED
(no change here and it matches chrome/x11), but LeaveNotify starts
to get translated to ET_MOUSE_EXITED.

This allows ozone/x11 chrome (external window mode) to hide tooltips
whenever cursor leaves a chrome window bound
(see TooltipController::OnMouseEvent).

BUG= 666958 

Change-Id: I8e134450d6014a8c8032c738f22ebf3d81d5e98f
Reviewed-on: https://chromium-review.googlesource.com/790611
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519542}
[modify] https://crrev.com/bcfb895bd39c421db37531d48accf340b4c0440f/ui/events/platform/x11/x11_event_source_libevent.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b1bdfe2694c98920e62f2affd2d9f0b5d0290dfc

commit b1bdfe2694c98920e62f2affd2d9f0b5d0290dfc
Author: Antonio Gomes <tonikitoo@igalia.com>
Date: Wed Nov 29 16:10:19 2017

[ozone/x11] Allow X11WindowBase::SetBounds proceed on hidden windows

Today, X11WindowBase::SetBounds bails out earlier when it is
called on a hidden window (i.e. when X11WindowBase::Show has
not been called yet).

Although this is Ok for ChromeOS/Ozone, where a native window
corresponds to a physical display, and accurate bounds provided at
its creation time, this breaks several cases in "external window mode"
(Linux/Ozone).

For instance, tooltips (which chrome/x11 has its on native window
for) are created with arbitrary temporary bounds - see DesktopWindowTreeHostX11::Init,
where 100x100 is used.
When bounds are available, DesktopWindowTreeHostX11::SetBoundsInPixels is called,
and only then DesktopWindowTreeHostX11::ShowImpl.

In 'external window mode', this behavior is also mimic'ed: arbitrary
(and temporary) bounds are also set so that an Ozone window is properly created,
but prior to showing it, Aura/Mus is expected to set proper bounds to it.

As is, Ozone's X11WindowBase, breaks this flow, since ::SetBounds conditions
its execution to 'X11WindowBase::window_mapped_' being true, an attribution
done in X11WindowBase::Show.

CL changes ozone/x11 so that it mimics chrome/x11 behavior, allowing
tooltips to be supported in external window mode, without changes
in on client side.

BUG= 666958 

Change-Id: Icc0490fe011ce3e19f08f161c7c0ff6cef9ef8f5
Reviewed-on: https://chromium-review.googlesource.com/791290
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520129}
[modify] https://crrev.com/b1bdfe2694c98920e62f2affd2d9f0b5d0290dfc/ui/platform_window/x11/x11_window_base.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/92649ee22541f53698978b8fd6f25e5e17302c92

commit 92649ee22541f53698978b8fd6f25e5e17302c92
Author: Antonio Gomes <tonikitoo@igalia.com>
Date: Fri Mar 09 17:03:26 2018

Prepare mus_demo for external window mode some more

This CL brings no functionality changes, to makes the CL [1]
that will bring external window mode capabilities to Mus slightly
smaller.

In summary it:

- removes a loose include in mus_demo_external.h
- adds a setter for the WindowTreeHostMus in WindowTreeData class,
  as a protected member (to be used by WindowTreeDataExternal in [1])
  and uses it.
- Conditions WindowTreeData::IsInitialized to 'window_delegate_' rather
  than to 'window_tree_host_'. Reason: after [1], window_tree_host_ will
  be initialized earlier on, and not reflect a WindowTreeData instance
  actually be initialized anymore.

BUG= 666958 

[1] https://crrev.com/c/955782

Change-Id: Ifec202d2217cfeafd9a13c7811610fbe450b9937
Reviewed-on: https://chromium-review.googlesource.com/957143
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Cr-Commit-Position: refs/heads/master@{#542145}
[modify] https://crrev.com/92649ee22541f53698978b8fd6f25e5e17302c92/services/ui/demo/mus_demo_external.h
[modify] https://crrev.com/92649ee22541f53698978b8fd6f25e5e17302c92/services/ui/demo/window_tree_data.cc
[modify] https://crrev.com/92649ee22541f53698978b8fd6f25e5e17302c92/services/ui/demo/window_tree_data.h

closed in favor of https://bugs.chromium.org/p/chromium/issues/detail?id=578890