Sadrul mentioned exo created a window sized to the screen. Where's the code that does this?

The code is in the android side. the android hwc will create a display sized exo surface as a container for all sub surfaces (android layers). And hwc will merge input regions of all android layers to one input region, and set it to the display sized exo surface.

Are you sure it isn't exo creating the aura::Window? Please correct me if I'm wrong, but in mushrome the Android side isn't directly connecting to mus, right? So, that would mean exo has to be creating the aura::Window. I see components/exo creating a couple of aura::Windows, but I don't readily see one the size of the screen. If an aura::Window is created the size of the screen, then my guess is we need to call SetEventTargetingPolicy(DESCENDANTS_ONLY).

I mean the exo will not create display sized aura::Window by itself. The android side code will create a display sized exo::Surface for every android window(app) via the wayland API, and set the input region on it.

Are these fullscreen windows created with LAYER_NOT_DRAWN? If not, can they be?

For an android app window,  the window hierarchy is looks like:

1 view::Widget -> 2 exo::SurfaceTreeHost::host_window_ -> 3 exo::Surface::window_(1 shell surface) -> 4 exo::Surface::window_ (several sub surface) 

1. It is a normal sized window.
2. It is display sized window. Exo creates frame sink from it, so it cannot be LAYER_NOT_DRAW.
3. This shell surface is display sized, so the Surface::window_ is also display sized. It is for event dispatching and it is LAYER_NOT_DRAWN.
4. Every subsurface also has an aura::window. They are for event display dispatching and they are LAYER_NOT_DRAW.

Is it possible to have the display-size window in 2 as LAYER_NOT_DRAWN, and create a frame-sink for the content-size window in 3 instead?

No. The shell surface 3 is a display sized surface, so the aura::Window in 3 has to be display sized.

Do you understand why a display sized sub window will cause the problem?The mouse clicks don't work before launching any android app. Is the display sized window causes the problem? 

Peng, could you execute control-alt-shift-s and paste the window hierarchy here?

[9103:9150:0828/134541.750153:ERROR:window_manager_state.cc(539)] ServerWindow hierarchy:
id=0:3 visible=true bounds=0,0 3200x1800 name=WindowManagerRoot
  id=1:1 visible=true bounds=0,0 3200x1800 name=RootWindow-0 [FrameSinkId(65537, 0)]
    id=1:2 visible=true bounds=0,0 3200x1800 name=ScreenRotationContainer
      id=1:3 visible=true bounds=0,0 3200x1800 name=WallpaperContainer
        id=1:44 visible=true bounds=0,0 3200x1800 name=WallpaperView
      id=1:4 visible=true bounds=0,0 3200x1800 name=NonLockScreenContainersContainer
        id=1:8 visible=false bounds=0,0 3200x1800 name=UnparentedControlContainer
        id=1:9 visible=true bounds=0,0 3200x1800 name=DefaultContainer
          id=1:31 visible=true bounds=500,32 2200x1672 name=(no name)
            id=1:33 visible=true bounds=0,224 2200x1448 name=NativeViewHostAuraClip
              id=1:34 visible=true bounds=0,0 2200x1448 name=WebContentsViewAura
                id=1:35 visible=true bounds=0,0 2200x1448 name=RenderWidgetHostViewAura [FrameSinkId(65571, 0)]
          id=1:43 visible=false bounds=498,1662 732x44 name=StatusBubble
          id=1:36 visible=true bounds=1994,162 708x272 name=BubbleDialogDelegateView
        id=1:10 visible=true bounds=0,0 3200x1800 name=AlwaysOnTopContainer
        id=1:11 visible=true bounds=0,0 3200x1800 name=AppListContainer
        id=1:12 visible=true bounds=0,0 3200x1800 name=ShelfContainer
          id=1:27 visible=true bounds=0,1704 3200x96 name=ShelfWidget
        id=1:13 visible=true bounds=0,0 3200x1800 name=PanelContainer
        id=1:14 visible=true bounds=0,0 3200x1800 name=ShelfBubbleContainer
        id=1:15 visible=true bounds=0,0 3200x1800 name=SystemModalContainer
          id=1:53 visible=true bounds=0,0 3200x1800 name=ExoShellSurface
            id=1:47 visible=true bounds=0,0 6400x3600 name=ExoShellSurfaceHost [FrameSinkId(65583, 0)]
              id=1:46 visible=true bounds=0,0 6400x3600 name=ExoSurface
      id=1:5 visible=true bounds=0,0 3200x1800 name=LockScreenWallpaperContainer
      id=1:6 visible=true bounds=0,0 3200x1800 name=LockScreenContainersContainer
        id=1:16 visible=true bounds=0,0 3200x1800 name=LockScreenContainer
        id=1:17 visible=true bounds=0,0 3200x1800 name=LockActionHandlerContainer
        id=1:18 visible=true bounds=0,0 3200x1800 name=LockSystemModalContainer
      id=1:7 visible=true bounds=0,0 3200x1800 name=LockScreenRelatedContainersContainer
        id=1:19 visible=true bounds=0,0 3200x1800 name=StatusContainer
          id=1:28 visible=true bounds=2846,1704 354x96 name=StatusAreaWidget
        id=1:20 visible=true bounds=0,0 3200x1800 name=SettingBubbleContainer
        id=1:21 visible=true bounds=0,0 3200x1800 name=VirtualKeyboardParentContainer
        id=1:22 visible=true bounds=0,0 3200x1800 name=MenuContainer
        id=1:23 visible=true bounds=0,0 3200x1800 name=DragImageAndTooltipContainer
        id=1:24 visible=true bounds=0,0 3200x1800 name=OverlayContainer
      id=1:25 visible=true bounds=0,0 3200x1800 name=MouseCursorContainer
      id=1:26 visible=true bounds=0,0 3200x1800 name=PowerButtonAnimationContainer

        id=1:15 visible=true bounds=0,0 3200x1800 name=SystemModalContainer
          id=1:53 visible=true bounds=0,0 3200x1800 name=ExoShellSurface
            id=1:47 visible=true bounds=0,0 6400x3600 name=ExoShellSurfaceHost [FrameSinkId(65583, 0)]
              id=1:46 visible=true bounds=0,0 6400x3600 name=ExoSurface

These are created automatically at Android bootup for Android system output.  However they should be not be capturing any input, not unless there is actual content to display. We initially create one window that is transparent, and is the size of the screen, to allow content to be placed anywhere on the screen relative to it. We only set up an input region when there is content, and optionally make it system modal if that is the type of Android dialog box it is.

Quick questions:

 1. Can you clarify why you need the fullscreen window to position the content anywhere on screen? Because we don't need this for the other kind of windows we have in aura/chrome.

 2. Can you make the fullscreen window be created with LAYER_NOT_DRAWN?

 3. Why does the window live as a child of the modal-container?

For 1, From the Android side, we are using the Wayland protocol to send Android windows to Chrome. One thing the protocol lacks by design is absolute positioning, so we are currently getting that feature by creating a full screen window and positioning children relative to it.

For 2 and 3, reveman@ might be a better person to respond as I'm not very familiar with the Chrome side once you get into what Exo is doing in response to Wayland requests.

I'm not sure I understand the motivation for (1). If you put the windows in the default container (the window with id 1:9 in the paste) you should have exactly the same positioning behavior.

The system model container is marked as having activatable children, which is likely why we're seeing some problems here.

If ExoShellSurface, ExoShellSurfaceHost and ExoSurface are intended as containers you should call SetEventTargetingPolicy(DESCENDANTS_ONLY). I think that would fix this. Secondarily I'm rather surprised those windows are visible all the time. Shouldn't they only be visible when you need them? And, as Sadrul asks, it seems they shouldn't need to draw.

It is hard to tell which window is for the Android system out. So I call SetEventTargetingPolicy(DESCENDANTS_ONLY) on ExoShellSurface, ExoShellSurfaceHost and ExoSurface for all exo windows. It fix the problem. But the cursor become invisible, when the cursor is moving on regular Android windows. Probably it is related to the change.

What does the hierarchy look like with an actual android window showing?

ServerWindow hierarchy with one android window (Google Play Store)
[25847:25891:0829/115541.665692:ERROR:window_manager_state.cc(539)] ServerWindow hierarchy:
id=0:3 visible=true bounds=0,0 3200x1800 name=WindowManagerRoot
  id=1:1 visible=true bounds=0,0 3200x1800 name=RootWindow-0 [FrameSinkId(65537, 0)]
    id=1:2 visible=true bounds=0,0 3200x1800 name=ScreenRotationContainer
      id=1:3 visible=true bounds=0,0 3200x1800 name=WallpaperContainer
        id=1:47 visible=true bounds=0,0 3200x1800 name=WallpaperView
      id=1:4 visible=true bounds=0,0 3200x1800 name=NonLockScreenContainersContainer
        id=1:8 visible=false bounds=0,0 3200x1800 name=UnparentedControlContainer
        id=1:9 visible=true bounds=0,0 3200x1800 name=DefaultContainer
          id=1:31 visible=true bounds=500,78 2200x1672 name=(no name)
            id=1:33 visible=true bounds=0,224 2200x1448 name=NativeViewHostAuraClip
              id=1:34 visible=true bounds=0,0 2200x1448 name=WebContentsViewAura
                id=1:35 visible=true bounds=0,0 2200x1448 name=RenderWidgetHostViewAura [FrameSinkId(65571, 0)]
          id=1:43 visible=false bounds=498,1708 732x44 name=StatusBubble
          id=1:36 visible=true bounds=1994,208 708x272 name=BubbleDialogDelegateView
          id=1:72 visible=true bounds=642,232 618x1098 name=ExoShellSurface
            id=1:73 visible=true bounds=2,2 616x1096 name=(no name)
            id=1:70 visible=true bounds=-642,-232 6400x3600 name=ExoShellSurfaceHost [FrameSinkId(65606, 0)]
              id=1:69 visible=true bounds=0,0 6400x3600 name=ExoSurface
                id=1:71 visible=true bounds=1286,466 1236x2196 name=ExoSurface
                id=1:68 visible=true bounds=1286,466 1236x2196 name=ExoSurface
        id=1:10 visible=true bounds=0,0 3200x1800 name=AlwaysOnTopContainer
        id=1:11 visible=true bounds=0,0 3200x1800 name=AppListContainer
        id=1:12 visible=true bounds=0,0 3200x1800 name=ShelfContainer
          id=1:27 visible=true bounds=0,1704 3200x96 name=ShelfWidget
        id=1:13 visible=true bounds=0,0 3200x1800 name=PanelContainer
        id=1:14 visible=true bounds=0,0 3200x1800 name=ShelfBubbleContainer
        id=1:15 visible=true bounds=0,0 3200x1800 name=SystemModalContainer
          id=1:63 visible=true bounds=0,0 3200x1800 name=ExoShellSurface
            id=1:53 visible=true bounds=0,0 6400x3600 name=ExoShellSurfaceHost [FrameSinkId(65589, 0)]
              id=1:52 visible=true bounds=0,0 6400x3600 name=ExoSurface
      id=1:5 visible=true bounds=0,0 3200x1800 name=LockScreenWallpaperContainer
      id=1:6 visible=true bounds=0,0 3200x1800 name=LockScreenContainersContainer
        id=1:16 visible=true bounds=0,0 3200x1800 name=LockScreenContainer
        id=1:17 visible=true bounds=0,0 3200x1800 name=LockActionHandlerContainer
        id=1:18 visible=true bounds=0,0 3200x1800 name=LockSystemModalContainer
      id=1:7 visible=true bounds=0,0 3200x1800 name=LockScreenRelatedContainersContainer
        id=1:19 visible=true bounds=0,0 3200x1800 name=StatusContainer
          id=1:28 visible=true bounds=2786,1704 414x96 name=StatusAreaWidget
        id=1:20 visible=true bounds=0,0 3200x1800 name=SettingBubbleContainer
        id=1:21 visible=true bounds=0,0 3200x1800 name=VirtualKeyboardParentContainer
        id=1:22 visible=true bounds=0,0 3200x1800 name=MenuContainer
        id=1:23 visible=true bounds=0,0 3200x1800 name=DragImageAndTooltipContainer
        id=1:24 visible=true bounds=0,0 3200x1800 name=OverlayContainer
      id=1:25 visible=true bounds=0,0 3200x1800 name=MouseCursorContainer
      id=1:26 visible=true bounds=0,0 3200x1800 name=PowerButtonAnimationContainer

It looks like 1:71 and 1:68 are the real windows from android, right? If that's the case, I wouldn't expect the cursor to hide. I will look into this shortly (I have to resolve a couple of other things, then need to find a device that supports android).

ExoShellSurface
  ExoShellSurfaceHost [FrameSinkId()]
    ExoSurface

In case no one has pointed this out yet, the reason for this hierarchy is:

- ExoShellSurface, this represents the window's bounds (it's "geometry" in the wayland world), the bounds that should be considered for layout purposes. Wayland clients can dynamically set this to any rectangle they desire. Note that as required by wayland protocol this should not clip output or limit input processing. It's just for layout purposes.

- ExoShellSurfaceHost, this is the actual contents. Typically larger than the parent ExoShellSurface. The layer hierarchy contained is submitted to the compositor using this.

- ExoSurface, this is going away. Here mostly because initial exo code was built by sending frames to the UI compositor instead of directly to the display compositor. Still used for event dispatch I think but we should hopefully be able to remove that too soon.

Arc++

There are some historic reasons for why Arc uses those confusing fullscreen windows. Technically Arc is just a fancy nested desktop. Like Xnest running on a Xserver or chromoting on ChromeOS. Initially it was just a single window with transparency and input clipping to integrate better than an opaque window. This was a simple and reliable first step that could be done using standard wayland protocol. Client (Android framework) control everything within the window that represents the client display. This doesn't allow android and chrome windows to be interleaved so to fix that we simply had the client (android) separate the layers of each task into separate fullscreen nested desktops. A lot has been added to that but that's still the basics behind the current design.

We're now looking at moving towards a more traditional client interface and the remote-shell wayland interface currently used by Arc++ will then be abandoned in favor of what I was planning to name aura-shell or cr-shell. This new interface would extend xdg-shell in a way that is consistent with interfaces such as gtk-shell on gnome desktop and expose Chrome specific WM API that is useful to clients such as Arc++. remote-shell was named 'remote' as it could be used for nested desktop functionality where windows are managed remotely and not by chrome.

The completely transparent fullscreen windows from Android are effectively LAYER_NOT_DRAW as they have opacity/alpha=0 and exo will ignore them when producing frames.

ARC++ sets the input region for every surface. In cash, we uses it for dispatching events. I think for mus, ws should know those input regions, so it can dispatch event correctly.

Will the input regions map to hit test regions?

Yes. We convert them to hit test regions and use them in aura::WindowDelegate in cash. But in mus, we didn't send them to window server or viz. Should we do it? and how?

Ria or Valery can answer that question.

+varkha@

components/exo has a few WindowTargeter overrides. Not sure whether we need all of them, but I guess at least some needs to provide the appropriate hit-test region(s)? It looks like the hit-test region is an SkRegion [1]. We can probably start with using the bounds [2] as the hit-test rectangle. But it may make sense to eventually switch to using an Iterator [3] to get all the rects in the region.

[1] https://cs.chromium.org/chromium/src/components/exo/surface.h?l=226
[2] https://cs.chromium.org/chromium/src/third_party/skia/include/core/SkRegion.h?l=85
[3] https://cs.chromium.org/chromium/src/third_party/skia/include/core/SkRegion.h?l=327

Yea we should get Surface::state_.input_region and collect all rects in it, then send to Viz similar to what HitTestDataProviderAura [1] is doing for Aura windows with shapes using ShapedAppWindowTargeter [2].

[1] https://cs.chromium.org/chromium/src/ui/aura/hit_test_data_provider_aura.h?type=cs&sq=package:chromium&l=19
[2] https://cs.chromium.org/chromium/src/chrome/browser/ui/views/apps/shaped_app_window_targeter.cc?type=cs&l=17

Owning this for triage in WAT.

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

commit 45e581ffd10f1df45a03c9ddbe9a8c71e6cf0f70
Author: Peng Huang <penghuang@google.com>
Date: Thu Sep 14 22:46:42 2017

exo: set event targeting policy for aura::Window in exo.

ARC++ always creates an invisible screen sized shell surface
for system window. It blocks pointer events for other
windows behind it. In mus, other windows are living in other
mus clients (processes), the mus window server will dispatch
all pointer events to the invisible screen sized shell surface.
This CL sets event targeting policy for all aura::Window created
by exo appropriately, so the mus window server can dispatch
pointer events correctly.

Known issue: the cursor for ARC++ is not displayed correctly.

Bug:  757542 
Change-Id: Iaa22e5e6c265dd5e48397f140b00dfb31af60c43
Reviewed-on: https://chromium-review.googlesource.com/667978
Reviewed-by: David Reveman <reveman@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#502061}
[modify] https://crrev.com/45e581ffd10f1df45a03c9ddbe9a8c71e6cf0f70/components/exo/shell_surface.cc
[modify] https://crrev.com/45e581ffd10f1df45a03c9ddbe9a8c71e6cf0f70/components/exo/surface.cc
[modify] https://crrev.com/45e581ffd10f1df45a03c9ddbe9a8c71e6cf0f70/components/exo/surface_tree_host.cc

I want to split what is in comments #29 and #30 out into a separate bug now that the blocker in Exo has landed. sg?

#35, filed  bug 766174 .

Since the new  bug 766174  is filed, close this one.

Is there a bug for ARC++ cursor?

Yes. I will file a separate bug for it.