mus: Add EventObserver to allow passively listening to UI events

components/mus/public/interfaces/window_tree.mojom

Index: components/mus/public/interfaces/window_tree.mojom
diff --git a/components/mus/public/interfaces/window_tree.mojom b/components/mus/public/interfaces/window_tree.mojom
index eb2ef580ef31b7b8fb99e0eab0494d16f6976ed4..f899c62f81e65cd9b66e6cb6943dc8e64b22f5eb 100644
--- a/components/mus/public/interfaces/window_tree.mojom
+++ b/components/mus/public/interfaces/window_tree.mojom
@@ -7,6 +7,7 @@ module mus.mojom;
 import "components/mus/public/interfaces/compositor_frame.mojom";
 import "components/mus/public/interfaces/cursor.mojom";
 import "components/mus/public/interfaces/input_events.mojom";
+import "components/mus/public/interfaces/input_event_matcher.mojom";
 import "components/mus/public/interfaces/mus_constants.mojom";
 import "components/mus/public/interfaces/surface_id.mojom";
 import "components/mus/public/interfaces/window_manager.mojom";
@@ -109,6 +110,14 @@ interface WindowTree {
   // if |window_id| does not currently have capture.
   ReleaseCapture(uint32 change_id, uint32 window_id);
 
+  // Sets an observer that monitors all events, even if they are not targeted
+  // at a window in this tree. If an event matchs |matcher| the observer reports
+  // it to the WindowTreeClient via OnWindowInputEvent (if the event target is
+  // this window tree) or OnEventObserved (if the target is another tree). The
+  // client must supply a non-zero |observer_id|, which is reported back with
+  // observed events.  Set the matcher to null to clear the observer.
+  SetEventObserver(EventMatcher? matcher, uint32 observer_id);

[sadrul, 2016/04/23 01:24:39]

This feels fairly awkward. What happens if multiple matchers match an event?

I think it's simpler to just not send a message to the client for the observer
when the client itself is the target. The client should already have enough
information to decide whether or not the local Mouse/PointerWatcher should
trigger or not. If we wanted to make this super clear, we could call this
ExternalEventObserver instead of just EventObserver. But the |observer_id| thing
feels weird.

[James Cook, 2016/04/25 16:23:35]

I don't understand. You can't have multiple EventMatchers, by design. It's up to
the client to decide what to do with matched events.

I went with this pattern because I wanted a single source of truth about whether
an event matched or not, and that felt like it should be the server.

Scott, do you have an opinion here?

[sadrul, 2016/04/25 16:33:34]

I realized this after I left the comment. My initial understanding from reading
this was that you could register multiple observers with different observer-id
and matcher.

I think it would be simpler to have a single
'Set[External]EventsToObserve(EventMatcher? matcher)'. The client-side
(PointerMatcher, etc.) would have to track the various kinds of events to watch
for anyway, e.g. some parts of a client could be interested in pointer-down
events (bubble-closer in ash_sysui), while some other parts could be interested
in pointer-move events (e.g. auto-hide/show shelf, also in ash_sysui), and the
client-lib would have to make sure one doesn't override the other. So, it would
make sense to simplify the server-side code.

[James Cook, 2016/04/25 16:52:00]

I agree that the observer_id thing feels weird (you're right that it seems to
imply you can set multiple observers).

I don't think the client is going to need to keep track of separate lists of who
is interested in which event. I would just implement it like EventHandler --
there's a master list of everyone interested in pointer events and the interface
looks like:

void OnMouseDown(const MouseEvent& event) {}
void OnMouseUp(const MouseEvent& event) {}
...

and various bits of UI just implement the methods for the event types they care
about. (This also makes it clear that not all event types are supported, and
that you can't event->SetHandled() or event->StopPropagation().)

Let's move to email -- I just sent mail to you and Scott, proposing that we
don't use EventMatcher at all. :-)

+
   // Sets the specified bounds of the specified window.
   SetWindowBounds(uint32 change_id, uint32 window_id, mojo.Rect bounds);
 
@@ -358,9 +367,18 @@ interface WindowTreeClient {
   // Invoked when an event is targeted at the specified window. The client must
   // call WindowTree::OnWindowInputEventAck() with the same |event_id| to notify
   // that the event has been processed, and with an EventResult value to notify
-  // if the event was consumed. The client will not receive farther events until
-  // the event is ack'ed.
-  OnWindowInputEvent(uint32 event_id, uint32 window, Event event);
+  // if the event was consumed. |event_observer_id| is non-zero if the event
+  // also matched the active event observer for this client. The client will not
+  // receive farther events until the event is ack'ed.
+  OnWindowInputEvent(uint32 event_id,
+                     uint32 window,
+                     Event event,
+                     uint32 event_observer_id);
+
+  // Invoked when an |event| is sent via the EventObserver and not targeted at a
+  // specific window. The |event_observer_id| is the one supplied to
+  // SetEventObserver. The client should not acknowledge these events.
+  OnEventObserved(Event event, uint32 event_observer_id);
 
   // Called in two distinct cases: when a window known to the connection gains
   // focus, or when focus moves from a window known to the connection to a