mus: Add EventObserver to allow passively listening to UI events

mus: Add EventObserver to allow passively listening to UI events

In order to close the system tray bubble, ash_sysui needs to be able
to listen for events that are not targeted to its windows.

* Add a SetEventObserver/ClearEventObserver interface to WindowTree.
* Event observers are set using the same mojom::EventMatchers used
  by accelerators.
* The window server tests incoming events from any display and sends
  them to all WindowTrees with a matching event observer that belong
  to the same user.

A follow-up CL will add a client-side "PointerWatcher" mechanism and
use it in ash_sysui to close the tray bubble.

BUG=599142
TEST=added to mus_ws_unittests

Committed: https://crrev.com/46fcd654384263357e045cb538e655e62a11f3f4
Cr-Commit-Position: refs/heads/master@{#389315}

[James Cook, 2016-04-21 16:36:25]

Description was changed from

==========
mus: Add EventObserver to allow passively listening to UI events

BUG=
==========

to

==========
mus: Add EventObserver to allow passively listening to UI events

In order to close the system tray bubble, ash_sysui needs to be able
to listen for events that are not targeted to its windows.

* Add a SetEventObserver/ClearEventObserver interface to WindowTree.
* Event observers are set using the same mojom::EventMatchers used
  by accelerators.
* The window server tests incoming events from any display and sends
  them to all WindowTrees with a matching event observer.

A follow-up CL will add a client-side "PointerWatcher" mechanism and
use it in ash_sysui to close the tray bubble.

BUG=599142
TEST=added to mus_ws_unittests
==========

[James Cook, 2016-04-21 16:42:37]

jamescook@chromium.org changed reviewers:
+ sky@chromium.org

[James Cook, 2016-04-21 16:42:37]

sky, please take a look.

I'm not thrilled with the name EventTester. I thought about calling it
EventMatcher and renaming mojom::EventMatcher to mojom::EventMatcherData, but
that's kind of awkward too, and the rename would touch enough files that I'd
prefer to do it in a separate CL.

Lemme know if you're OK with EventTester, or if you'd like me to do the
EventMatcher rename, or if you have a better name suggestion. :-)

[sky, 2016-04-21 17:23:02]

sky@chromium.org changed reviewers:
+ sadrul@chromium.org

[sky, 2016-04-21 17:23:04]

+sadrul

https://codereview.chromium.org/1909733002/diff/20001/components/mus/public/i...
File components/mus/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/1909733002/diff/20001/components/mus/public/i...
components/mus/public/interfaces/window_tree.mojom:117:
SetEventObserver(EventMatcher matcher);
Declare this as EventMatcher?, then you can pass in null and don't need clear.

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/event...
File components/mus/ws/event_tester.h (right):

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/event...
components/mus/ws/event_tester.h:20: // Wraps a mojom::EventMatcher and allows
events to be tested against it.
The reason we started putting the interfaces/structures declared in mojoms
inside the mojom namespace is so that you can use the same name. So, I would
name this EventMatcher.

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
File components/mus/ws/window_manager_state.cc (right):

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
components/mus/ws/window_manager_state.cc:236:
window_server()->SendToEventObservers(event);
This comment doesn't match with the code. This function is called when Display
gets an Event, before EventDispatcher has processed the event.

If you want to send after the event has been acked I would expect this code to
be in OnEventAck (and you'll have to deal with the client we're waiting on going
away).

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
File components/mus/ws/window_server.cc (right):

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
components/mus/ws/window_server.cc:403: for (auto& pair : tree_map_) {
nit: no {}

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
File components/mus/ws/window_tree.cc (right):

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
components/mus/ws/window_tree.cc:962:
client()->OnEventObserved(mojom::Event::From(event));
If the event was targetted at this client, then I wouldn't sent it again.
Additionally don't send events to windowtrees of inactive users.

[sadrul, 2016-04-21 19:15:29]

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
File components/mus/ws/window_server.cc (right):

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
components/mus/ws/window_server.cc:405: }
It should send only if the requestor and the target of |event| is the same user.

[James Cook, 2016-04-22 18:17:46]

Description was changed from

==========
mus: Add EventObserver to allow passively listening to UI events

In order to close the system tray bubble, ash_sysui needs to be able
to listen for events that are not targeted to its windows.

* Add a SetEventObserver/ClearEventObserver interface to WindowTree.
* Event observers are set using the same mojom::EventMatchers used
  by accelerators.
* The window server tests incoming events from any display and sends
  them to all WindowTrees with a matching event observer.

A follow-up CL will add a client-side "PointerWatcher" mechanism and
use it in ash_sysui to close the tray bubble.

BUG=599142
TEST=added to mus_ws_unittests
==========

to

==========
mus: Add EventObserver to allow passively listening to UI events

In order to close the system tray bubble, ash_sysui needs to be able
to listen for events that are not targeted to its windows.

* Add a SetEventObserver/ClearEventObserver interface to WindowTree.
* Event observers are set using the same mojom::EventMatchers used
  by accelerators.
* The window server tests incoming events from any display and sends
  them to all WindowTrees with a matching event observer that belong
  to the same user.

A follow-up CL will add a client-side "PointerWatcher" mechanism and
use it in ash_sysui to close the tray bubble.

BUG=599142
TEST=added to mus_ws_unittests
==========

[James Cook, 2016-04-22 18:22:55]

sky, please take a look.

I decided to keep two functions in the mojo WindowTreeClient interface:
OnWindowInputEvent - always has a target, always must be acked, might have
matched an EventObserver
OnEventObserved - didn't hit a target, doesn't need ack

I tried putting everything into OnWindowInputEvent, but I think it's a little
confusing that acking is only required sometimes.

https://codereview.chromium.org/1909733002/diff/20001/components/mus/public/i...
File components/mus/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/1909733002/diff/20001/components/mus/public/i...
components/mus/public/interfaces/window_tree.mojom:117:
SetEventObserver(EventMatcher matcher);
On 2016/04/21 17:23:03, sky wrote:
> Declare this as EventMatcher?, then you can pass in null and don't need clear.

Done.

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/event...
File components/mus/ws/event_tester.h (right):

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/event...
components/mus/ws/event_tester.h:20: // Wraps a mojom::EventMatcher and allows
events to be tested against it.
On 2016/04/21 17:23:03, sky wrote:
> The reason we started putting the interfaces/structures declared in mojoms
> inside the mojom namespace is so that you can use the same name. So, I would
> name this EventMatcher.

Done. There was a different file called event_matcher.h in
components/mus/public/cpp/, but that one just contains a single utility function
to build a mojom::EventMatcher. I renamed it to event_matcher_util.h because I
think have two event_matcher.h files is potentially confusing.

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
File components/mus/ws/window_manager_state.cc (right):

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
components/mus/ws/window_manager_state.cc:236:
window_server()->SendToEventObservers(event);
On 2016/04/21 17:23:03, sky wrote:
> This comment doesn't match with the code. This function is called when Display
> gets an Event, before EventDispatcher has processed the event.
> 
> If you want to send after the event has been acked I would expect this code to
> be in OnEventAck (and you'll have to deal with the client we're waiting on
going
> away).

This code is gone.

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
File components/mus/ws/window_server.cc (right):

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
components/mus/ws/window_server.cc:403: for (auto& pair : tree_map_) {
On 2016/04/21 17:23:04, sky wrote:
> nit: no {}

Done.

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
components/mus/ws/window_server.cc:405: }
On 2016/04/21 19:15:29, sadrul wrote:
> It should send only if the requestor and the target of |event| is the same
user.

Done.

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
File components/mus/ws/window_tree.cc (right):

https://codereview.chromium.org/1909733002/diff/20001/components/mus/ws/windo...
components/mus/ws/window_tree.cc:962:
client()->OnEventObserved(mojom::Event::From(event));
On 2016/04/21 17:23:04, sky wrote:
> If the event was targetted at this client, then I wouldn't sent it again.
> Additionally don't send events to windowtrees of inactive users.

Done.

[sky, 2016-04-22 20:18:48]

https://codereview.chromium.org/1909733002/diff/30001/components/mus/public/i...
File components/mus/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/1909733002/diff/30001/components/mus/public/i...
components/mus/public/interfaces/window_tree.mojom:374: bool matched_observer);
Rather than a bool for matched_observer I think you should use an id. If you
don't use an id it means the client doesn't have a way to ensure they know which
eventmatcher matched. For example. Lets say the client has an EventMatcher
installed and wants to replace it with a new one. If there was an in flight
event that only matched the first eventmatcher the client will send it to the
wrong place.

I recommend having SetEventObserver take a client assigned int it that is passed
through OnWindowInputEvent.

https://codereview.chromium.org/1909733002/diff/30001/components/mus/public/i...
components/mus/public/interfaces/window_tree.mojom:377: // specific window. The
client does not need to acknowledge these events.
'does not need to' -> should not

https://codereview.chromium.org/1909733002/diff/30001/components/mus/ws/event...
File components/mus/ws/event_dispatcher_delegate.h (right):

https://codereview.chromium.org/1909733002/diff/30001/components/mus/ws/event...
components/mus/ws/event_dispatcher_delegate.h:44: // Called when event dispatch
could not find a target.
Clarify that OnAccelerator may still be called.

[James Cook, 2016-04-22 21:25:08]

sky, please take another look.

https://codereview.chromium.org/1909733002/diff/30001/components/mus/public/i...
File components/mus/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/1909733002/diff/30001/components/mus/public/i...
components/mus/public/interfaces/window_tree.mojom:374: bool matched_observer);
On 2016/04/22 20:18:48, sky wrote:
> Rather than a bool for matched_observer I think you should use an id. If you
> don't use an id it means the client doesn't have a way to ensure they know
which
> eventmatcher matched. For example. Lets say the client has an EventMatcher
> installed and wants to replace it with a new one. If there was an in flight
> event that only matched the first eventmatcher the client will send it to the
> wrong place.
> 
> I recommend having SetEventObserver take a client assigned int it that is
passed
> through OnWindowInputEvent.

Done.

https://codereview.chromium.org/1909733002/diff/30001/components/mus/public/i...
components/mus/public/interfaces/window_tree.mojom:377: // specific window. The
client does not need to acknowledge these events.
On 2016/04/22 20:18:48, sky wrote:
> 'does not need to' -> should not

Done.

https://codereview.chromium.org/1909733002/diff/30001/components/mus/ws/event...
File components/mus/ws/event_dispatcher_delegate.h (right):

https://codereview.chromium.org/1909733002/diff/30001/components/mus/ws/event...
components/mus/ws/event_dispatcher_delegate.h:44: // Called when event dispatch
could not find a target.
On 2016/04/22 20:18:48, sky wrote:
> Clarify that OnAccelerator may still be called.

Done.

[sky, 2016-04-22 21:42:12]

LGTM

[James Cook, 2016-04-22 22:38:01]

The CQ bit was checked by jamescook@chromium.org

[James Cook, 2016-04-22 22:38:01]

The patchset sent to the CQ was uploaded after l-g-t-m from sky@chromium.org
Link to the patchset: https://codereview.chromium.org/1909733002/#ps70001
(title: "rebase")

[commit-bot: I haz the power, 2016-04-22 22:38:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1909733002/70001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1909733002/70001

[commit-bot: I haz the power, 2016-04-23 00:03:16]

Description was changed from

==========
mus: Add EventObserver to allow passively listening to UI events

In order to close the system tray bubble, ash_sysui needs to be able
to listen for events that are not targeted to its windows.

* Add a SetEventObserver/ClearEventObserver interface to WindowTree.
* Event observers are set using the same mojom::EventMatchers used
  by accelerators.
* The window server tests incoming events from any display and sends
  them to all WindowTrees with a matching event observer that belong
  to the same user.

A follow-up CL will add a client-side "PointerWatcher" mechanism and
use it in ash_sysui to close the tray bubble.

BUG=599142
TEST=added to mus_ws_unittests
==========

to

==========
mus: Add EventObserver to allow passively listening to UI events

In order to close the system tray bubble, ash_sysui needs to be able
to listen for events that are not targeted to its windows.

* Add a SetEventObserver/ClearEventObserver interface to WindowTree.
* Event observers are set using the same mojom::EventMatchers used
  by accelerators.
* The window server tests incoming events from any display and sends
  them to all WindowTrees with a matching event observer that belong
  to the same user.

A follow-up CL will add a client-side "PointerWatcher" mechanism and
use it in ash_sysui to close the tray bubble.

BUG=599142
TEST=added to mus_ws_unittests
==========

[commit-bot: I haz the power, 2016-04-23 00:03:17]

Committed patchset #5 (id:70001)

[commit-bot: I haz the power, 2016-04-23 00:05:19]

Description was changed from

==========
mus: Add EventObserver to allow passively listening to UI events

In order to close the system tray bubble, ash_sysui needs to be able
to listen for events that are not targeted to its windows.

* Add a SetEventObserver/ClearEventObserver interface to WindowTree.
* Event observers are set using the same mojom::EventMatchers used
  by accelerators.
* The window server tests incoming events from any display and sends
  them to all WindowTrees with a matching event observer that belong
  to the same user.

A follow-up CL will add a client-side "PointerWatcher" mechanism and
use it in ash_sysui to close the tray bubble.

BUG=599142
TEST=added to mus_ws_unittests
==========

to

==========
mus: Add EventObserver to allow passively listening to UI events

In order to close the system tray bubble, ash_sysui needs to be able
to listen for events that are not targeted to its windows.

* Add a SetEventObserver/ClearEventObserver interface to WindowTree.
* Event observers are set using the same mojom::EventMatchers used
  by accelerators.
* The window server tests incoming events from any display and sends
  them to all WindowTrees with a matching event observer that belong
  to the same user.

A follow-up CL will add a client-side "PointerWatcher" mechanism and
use it in ash_sysui to close the tray bubble.

BUG=599142
TEST=added to mus_ws_unittests

Committed: https://crrev.com/46fcd654384263357e045cb538e655e62a11f3f4
Cr-Commit-Position: refs/heads/master@{#389315}
==========

[commit-bot: I haz the power, 2016-04-23 00:05:20]

Patchset 5 (id:??) landed as
https://crrev.com/46fcd654384263357e045cb538e655e62a11f3f4
Cr-Commit-Position: refs/heads/master@{#389315}

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

https://codereview.chromium.org/1909733002/diff/70001/components/mus/public/i...
File components/mus/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/1909733002/diff/70001/components/mus/public/i...
components/mus/public/interfaces/window_tree.mojom:119:
SetEventObserver(EventMatcher? matcher, uint32 observer_id);
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]

https://codereview.chromium.org/1909733002/diff/70001/components/mus/public/i...
File components/mus/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/1909733002/diff/70001/components/mus/public/i...
components/mus/public/interfaces/window_tree.mojom:119:
SetEventObserver(EventMatcher? matcher, uint32 observer_id);
On 2016/04/23 01:24:39, sadrul wrote:
> 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.

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]

https://codereview.chromium.org/1909733002/diff/70001/components/mus/public/i...
File components/mus/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/1909733002/diff/70001/components/mus/public/i...
components/mus/public/interfaces/window_tree.mojom:119:
SetEventObserver(EventMatcher? matcher, uint32 observer_id);
On 2016/04/25 16:23:35, James Cook wrote:
> On 2016/04/23 01:24:39, sadrul wrote:
> > 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.
> 
> I don't understand. You can't have multiple EventMatchers, by design.

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.

> 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?

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

https://codereview.chromium.org/1909733002/diff/70001/components/mus/public/i...
File components/mus/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/1909733002/diff/70001/components/mus/public/i...
components/mus/public/interfaces/window_tree.mojom:119:
SetEventObserver(EventMatcher? matcher, uint32 observer_id);
On 2016/04/25 16:33:34, sadrul wrote:
> On 2016/04/25 16:23:35, James Cook wrote:
> > On 2016/04/23 01:24:39, sadrul wrote:
> > > 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.
> > 
> > I don't understand. You can't have multiple EventMatchers, by design.
> 
> 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.
> 
> > 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?

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. :-)

[sky, 2016-04-25 18:24:06]

I actually like what you have here and like the id for the reasons I
asked for early in the review. Will respond to your other email
shortly.

  -Scott

On Mon, Apr 25, 2016 at 9:52 AM,  <jamescook@chromium.org> wrote:
>
>
https://codereview.chromium.org/1909733002/diff/70001/components/mus/public/i...
> File components/mus/public/interfaces/window_tree.mojom (right):
>
>
https://codereview.chromium.org/1909733002/diff/70001/components/mus/public/i...
> components/mus/public/interfaces/window_tree.mojom:119:
> SetEventObserver(EventMatcher? matcher, uint32 observer_id);
> On 2016/04/25 16:33:34, sadrul wrote:
>> On 2016/04/25 16:23:35, James Cook wrote:
>> > On 2016/04/23 01:24:39, sadrul wrote:
>> > > 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.
>> >
>> > I don't understand. You can't have multiple EventMatchers, by
> design.
>>
>> 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.
>>
>> > 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?
>
> 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. :-)
>
> https://codereview.chromium.org/1909733002/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.