Prevent the context menu from showing when long pressing the window controls

ui/views/view.cc

 // Copyright (c) 2012 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.
 
 #define _USE_MATH_DEFINES // For VC++ to get M_PI. This has to be first.
 
 #include "ui/views/view.h"
 
 #include <algorithm>
 #include <cmath>
@@ skipping 83 matching lines @@
 class PostEventDispatchHandler : public ui::EventHandler {
  public:
   explicit PostEventDispatchHandler(View* owner)
       : owner_(owner),
         touch_dnd_enabled_(switches::IsTouchDragDropEnabled()) {
   }
   virtual ~PostEventDispatchHandler() {}
 
  private:
   // Overridden from ui::EventHandler:
   virtual void OnGestureEvent(ui::GestureEvent* event) OVERRIDE {

[tdanderson, 2014/05/22 14:40:37]

In response to Sadrul's suggestion, I actually don't think we want an early
return here if owner_ != event->target(). 

Consider view A with the child view B, both having post-target handlers
installed. Say an event is targeted at B, but B is not draggable and does not
have a context menu controller. It might still be the case that A is
draggable/have a context menu controller, and the early return would disallow
dragging/a context menu for A.

Peter, can you double-check this?

[sadrul, 2014/05/22 14:50:53]

But the event is going to be retargeted to A if B did not handle it, right? If
there is a pre-target handler on A that wants to do something else (or if the
default handler of A does something with the event), then we should not do this
drag?

[tdanderson, 2014/05/22 16:08:20]

Wouldn't the early return when owner_ != event->target() defeat the purpose of
considering the post-target handlers of the target as well as all of the
post-target handlers of the target's ancestors during the post-target phase?

If a pre-target handler of A wanted to do something with the event, it had the
chance to do so during the pre-target phase before the event reaches B.

If A itself wants to do something with the event, it should only be allowed to
do so after the post-target phase for B's dispatch completes (which includes
possibly showing a context menu for A).

[sadrul, 2014/05/22 16:26:22]

Consider the case of B: whether or not the context menu of B is shown (or a drag
starts from B) depends on whether the default handler of B processed the event
or not. The same should apply for A. The default handler of A should get a
chance to process the event first.

It is entirely possible for a post-target handler of A do something during the
post-dispatch phase for target B, but in this case for context-menu/dnd, doing
that would be wrong. (if the code showed the context menu of the target instead
of owner_, then it would have made more sense).

Maybe the better fix is to install this handler on the root-view instead, and
show the context-menu/start dnd on the target.

[tdanderson, 2014/05/22 18:35:10]

OK, so your concern here is specific to context menus / touch d&d and you are
not objecting in general to the order of handlers visited during dispatch. In
that case, I am now on the same page as you.
I agree. Doing so will avoid the need to have a separate EventHandler for each
View and will also make the point conversion at line 112 unnecessary.

     DCHECK_EQ(ui::EP_POSTTARGET, event->phase());
     if (event->handled())
       return;
 
     if (touch_dnd_enabled_) {
-      if (event->type() == ui::ET_GESTURE_LONG_PRESS &&
-          (!owner_->drag_controller() ||
-           owner_->drag_controller()->CanStartDragForView(
-              owner_, event->location(), event->location()))) {
-        if (owner_->DoDrag(*event, event->location(),
-            ui::DragDropTypes::DRAG_EVENT_SOURCE_TOUCH)) {
-          event->StopPropagation();
-          return;
+      if (event->type() == ui::ET_GESTURE_LONG_PRESS) {
+        gfx::Point location(event->location());
+        View::ConvertPointToTarget(static_cast<View*>(event->target()),
+            owner_, &location);
+        if (!owner_->drag_controller() ||
+            owner_->drag_controller()->CanStartDragForView(
+                owner_, location, location)) {
+          if (owner_->DoDrag(*event, location,
+              ui::DragDropTypes::DRAG_EVENT_SOURCE_TOUCH)) {
+            event->StopPropagation();
+            return;
+          }
         }
       }
     }
 
     if (owner_->context_menu_controller() &&
         (event->type() == ui::ET_GESTURE_LONG_PRESS ||
          event->type() == ui::ET_GESTURE_LONG_TAP ||
          event->type() == ui::ET_GESTURE_TWO_FINGER_TAP)) {
       gfx::Point location(event->location());
-      View::ConvertPointToScreen(owner_, &location);
+      View::ConvertPointToScreen(
+          static_cast<View*>(event->target()), &location);
       owner_->ShowContextMenu(location, ui::MENU_SOURCE_TOUCH);
       event->StopPropagation();
     }
   }
 
   View* owner_;
   bool touch_dnd_enabled_;
 
   DISALLOW_COPY_AND_ASSIGN(PostEventDispatchHandler);
 };
@@ skipping 2397 matching lines @@
   // Message the RootView to do the drag and drop. That way if we're removed
   // the RootView can detect it and avoid calling us back.
   gfx::Point widget_location(event.location());
   ConvertPointToWidget(this, &widget_location);
   widget->RunShellDrag(this, data, widget_location, drag_operations, source);
   // WARNING: we may have been deleted.
   return true;
 }
 
 }  // namespace views