mash: Don't close system tray bubble for clicks in menus/notifications

ui/views/pointer_watcher.h

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef UI_VIEWS_POINTER_WATCHER_H_
 #define UI_VIEWS_POINTER_WATCHER_H_
 
 #include "ui/views/views_export.h"
 
 namespace gfx {
 class Point;
 }
 
 namespace ui {
 class MouseEvent;
 class TouchEvent;
 }
 
 namespace views {
+class Widget;
 
-// An interface for read-only observation of pointer events (in particular, the
-// events cannot be marked as handled). Only certain event types are supported.
-// NOTE: The event.target is always null, because on mus the target window may
-// be owned by another process.
+// An interface for observation of pointer events. The |target| is the
+// top-level widget that will receive the event, if any.
+// NOTE: On mus this allows observation of events outside of windows owned
+// by the current process, in which case the |target| will be null.
 class VIEWS_EXPORT PointerWatcher {
  public:
   virtual ~PointerWatcher() {}
 
-  virtual void OnMousePressed(const ui::MouseEvent& event,
-                              const gfx::Point& location_in_screen) = 0;
-  virtual void OnTouchPressed(const ui::TouchEvent& event,
-                              const gfx::Point& location_in_screen) = 0;
+  virtual void OnMousePressed(const gfx::Point& location_in_screen,
+                              Widget* target) = 0;
+  virtual void OnTouchPressed(const gfx::Point& location_in_screen,

[sadrul, 2016/05/06 17:28:26]

I would still keep these as Events if possible. Observers often want additional
info about the specific event (e.g. was the shift key down, was the
middle-button clicked, and so on)

[James Cook, 2016/05/06 17:46:35]

I intentionally removed the |event| because I'm concerned that some of the
fields are not valid in PointerWatchers, in particular event.target, and I
didn't want PointerWatcher users to have to think about which fields are valid
and which aren't. (I'm not sure event.root_location is currently valid either.)
My intent was to add event flag/modifier key parameters to the PointerWatcher
callbacks as I found cases that needed them.

How strongly do you feel about this?  (It's trivial for me to add the parameter
back.)

[sadrul, 2016/05/06 21:46:30]

I don't really think this is going to be an issue.
I think sending the whole event is better, and I would prefer if we did that
from the start. Updating these to later include additional information about the
event as separate parameters would need to update a lot of existing code, and
isn't that nice API-wise either.

A cleaner option may be to separate out the dispatch-related info from events
(i.e. target, phase, result), since that's the part that's not entirely
available here, but honestly, I don't think not having these data in Event is
going to be a problem.

[James Cook, 2016/05/06 22:46:24]

Done.

+                              Widget* target) = 0;
 };
 
 }  // namespace views
 
 #endif  // UI_VIEWS_POINTER_WATCHER_H_