so there are several issues here:

1) In multi displays environment. 
   https://codereview.chromium.org/2070163002/ should fix this

2) Arc++ window can still receive any mouse/touch events in system modal right now.
 It's using custom window targer and I'm wondering if it's related.

3) touch/mousewheel event goes to the target. It almost looks like it's using different
  path to deliver events to the target.

sadrul@ do you have any clue? It looks like it's somehow bypassing pre event handler.

+reveman@ to let him know this issue. 

A couple of findings:

1) A pretarget handler added to ash::Shell (for modality control) doesn't get called for arc++ windows, which has a custom targeter.
  (https://cs.chromium.org/chromium/src/components/exo/shell_surface.cc?rcl=0&l=65)

2) Mouse wheel/touch (gesture) events bypasses this pretarget handler.

* Prepending the this pre event handler to aura::Env::GetInstance() fixes 1), but not 2).

sadrul@, do you have any clue about these behaviors?

Looks like that SystemModalContainerEventFinder isn't filtering all events, so 2) should be it.

I still don't fully understand why adding custom targeter affects 1) behavior.

Another odd thing is that 2) does not happen when running on linux desktop.

sadrul@ ?

actually, 2) was because mouse wheel was filtered, but gestuer/scroll event were not.

So only question now is 1) in #2

So I think we are doing event-dispatch incorrectly for modal windows (both in  SystemModalContainerEventFilter and WindowModalityController ... I am not even sure why we have both instead of just one). Instead of using pre-target handlers, we should really start using event-targeter to make sure events are routed to modal windows correctly.

re (1) (in comment #2) I am not sure why this would happen. Can you confirm what ash window-container the arc++ windows live in. I ask since it looks like sometimes the arc++ window could live in the system-modal container (https://cs.chromium.org/chromium/src/components/exo/wayland/server.cc?rcl=1466219841&l=1607), which may explain this. Also, it looks like Touch (https://cs.chromium.org/chromium/src/components/exo/touch.cc?l=35) and Pointer (https://cs.chromium.org/chromium/src/components/exo/pointer.cc?l=42) add themselves as pre-target handlers on ash::Shell, which may also explain why the modality-filters don't get to block the events.

re (2) SystemModalContainerEventFilter should likely look at all events (i.e. it should just override EventHandler::OnEvent() so it catches all events). But ideally, we would use EventTarget instead of a pre-target handler.

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

commit 9a61ecf55390bfbaa15ec3da2ad529bda9d63e9c
Author: oshima <oshima@chromium.org>
Date: Sat Jun 18 10:43:05 2016

Fix "modal isn't modal in  multi displays" issue

This is pretty bad bug because you can do almost everything while system modal dialog is open.

* Generalized the logic to check if the window is above blocking container.

I believe I kept the original behavior otherwise. Please let me know if you noticed something different.

BUG= 620406 
TEST=manual, covered by tests

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

[modify] https://crrev.com/9a61ecf55390bfbaa15ec3da2ad529bda9d63e9c/ash/root_window_controller.cc
[modify] https://crrev.com/9a61ecf55390bfbaa15ec3da2ad529bda9d63e9c/ash/root_window_controller.h
[modify] https://crrev.com/9a61ecf55390bfbaa15ec3da2ad529bda9d63e9c/ash/shell.cc
[modify] https://crrev.com/9a61ecf55390bfbaa15ec3da2ad529bda9d63e9c/ash/wm/event_client_impl.cc
[modify] https://crrev.com/9a61ecf55390bfbaa15ec3da2ad529bda9d63e9c/ash/wm/system_modal_container_layout_manager.cc
[modify] https://crrev.com/9a61ecf55390bfbaa15ec3da2ad529bda9d63e9c/ash/wm/system_modal_container_layout_manager.h
[modify] https://crrev.com/9a61ecf55390bfbaa15ec3da2ad529bda9d63e9c/ash/wm/system_modal_container_layout_manager_unittest.cc

WindowModalityController is for window modal, which is different. 

I believe we talked about using WindowTargeter a while ago, but that never happened. That's being said, modality does not mean that we should always route to the modal windows (menu, keyboard, external displays etc), but want to prevent windows below modal layer from handing events,
so we should be careful about it.

For 2), I sent you CL.

For 1), yes pointer.cc was the culprit. I'm not sure why I couldn't catch when I searched it. Thanks.

reveman@, looks like pointer.cc is *handing* event in pretarget handler, which is not really meant for. Is there any reason why you're using pre target handler?

> For 2), I sent you CL.

Oops, sorry I mixed up with another CL that I sent  you.

It's https://codereview.chromium.org/2071423003/, in case you're interested.

@#7, the wayland interfaces for input are a bit different than our normal event dispatch mechanism in Chrome. Clients can instantiate pointer, touch, keyboard objects that generate events for all client owned surfaces and the target surface is a parameter of the events rather than the target of events. Using a pre-target handler was a clean way to implement this but it can probably be avoided with some refectoring. More details about the wayland interfaces here:

https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_seat

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

commit 4a69b3b040908d2d0414af656c82c77705929bfb
Author: oshima <oshima@chromium.org>
Date: Mon Jun 20 19:32:49 2016

Filter all events in SystemModalContainerEventHandler

BUG= 620406 
TEST=covered by unit test, manual

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

[modify] https://crrev.com/4a69b3b040908d2d0414af656c82c77705929bfb/ash/wm/system_modal_container_event_filter.cc
[modify] https://crrev.com/4a69b3b040908d2d0414af656c82c77705929bfb/ash/wm/system_modal_container_event_filter.h
[modify] https://crrev.com/4a69b3b040908d2d0414af656c82c77705929bfb/ash/wm/system_modal_container_layout_manager_unittest.cc

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

commit d30ca227f842be5125d94cea8b4ccf9d9314b8c2
Author: oshima <oshima@chromium.org>
Date: Mon Jun 27 04:18:33 2016

Make system modal check more strict

* Take visibility into account
* Make it system  modal only when MODAL_TYPE_SYSTEM is set.
  - DCHECK if the modal is set to other modal type.

BUG= 620406 
TEST=covered by unittest

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

[modify] https://crrev.com/d30ca227f842be5125d94cea8b4ccf9d9314b8c2/ash/wm/system_modal_container_layout_manager.cc
[modify] https://crrev.com/d30ca227f842be5125d94cea8b4ccf9d9314b8c2/ash/wm/system_modal_container_layout_manager.h
[modify] https://crrev.com/d30ca227f842be5125d94cea8b4ccf9d9314b8c2/ash/wm/system_modal_container_layout_manager_unittest.cc

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot