Allow menus to stay open during a child view's drag and drop

ui/views/widget/widget.cc

Index: ui/views/widget/widget.cc
diff --git a/ui/views/widget/widget.cc b/ui/views/widget/widget.cc
index fdcb32af915e97a73fead05becf0ac0c83dece35..538240f8c6d5c06a6bd41dbccaea4ebfc3d7ed8b 100644
--- a/ui/views/widget/widget.cc
+++ b/ui/views/widget/widget.cc
@@ -158,6 +158,7 @@ Widget::Widget()
       widget_delegate_(NULL),
       non_client_view_(NULL),
       dragged_view_(NULL),
+      child_drag_in_progress_(false),
       ownership_(InitParams::NATIVE_WIDGET_OWNS_WIDGET),
       is_secondary_widget_(true),
       frame_type_(FRAME_TYPE_DEFAULT),
@@ -787,9 +788,11 @@ void Widget::RunShellDrag(View* view,
                           int operation,
                           ui::DragDropTypes::DragEventSource source) {
   dragged_view_ = view;
+  GetTopLevelWidget()->set_child_drag_in_progress(true);

[sky, 2014/07/10 15:05:00]

You shouldn't need a new field to determine if a drag is in progress. You can
use dragged_view_ set on 790.

[Devlin, 2014/07/10 15:33:00]

The issue there is that dragged_view_ is typically for the direct widget.  In
this particular case, the widget associated with the dragging view will always
be the top level menu widget, but it seemed like that was a coincidence, rather
than a guarantee.  Will that be the case in all scenarios we should care about? 
If so, then this becomes a very nice one line fix to at least prevent the menu
from closing. :)

   native_widget_->RunShellDrag(view, data, location, operation, source);
   // If the view is removed during the drag operation, dragged_view_ is set to
   // NULL.
+  GetTopLevelWidget()->set_child_drag_in_progress(false);

[Devlin, 2014/07/09 18:28:44]

This still has the problem that, since capture was lost, we don't receive new
CaptureLost events, but I'll address that once we know whether it's worth
continuing with this approach or not.

[sky, 2014/07/10 15:05:00]

More specifically the menu is left in a weird state. I suspect we want to leave
the menu open and working normally, is that correct? If so, then you'll need to
open some methods on Widget that are called before/after this function so that
MenuController can do the right thing.

[Devlin, 2014/07/10 15:33:00]

Yeah, I would assume that we want to leave the menu open and working normally. 
A few notes:
- This would actually be slightly different than current behavior for
drag-and-drop in a menu, since that typically closes the menu as a result of
MenuController::OnDragExited (easy example: move around bookmarks in the wrench
menu).  Personally, I think this is a bit jarring, and for something where we
don't offer another UI surface (e.g., extension actions), it seems like we
shouldn't be closing after a drag-and-drop.
- Simply returning the capture to the widget with SetCapture() fixes half the
problem, in that it does mean that capture lost events will once again get sent
(so that clicking outside the menu will close it), but the menu doesn't seem to
be running entirely normally.

   if (view && dragged_view_ == view) {
     dragged_view_ = NULL;
     view->OnDragDone();