Prevents crash when a menu gets closed during drag

ui/views/controls/menu/menu_host.cc

Index: ui/views/controls/menu/menu_host.cc
diff --git a/ui/views/controls/menu/menu_host.cc b/ui/views/controls/menu/menu_host.cc
index 5e8593b98ab06b57bc2e780541d1fe18b8f904b4..28fb95e02a612c2cd3dc59e24f7a4ee262e8a9cc 100644
--- a/ui/views/controls/menu/menu_host.cc
+++ b/ui/views/controls/menu/menu_host.cc
@@ -92,6 +92,10 @@ void MenuHost::DestroyMenuHost() {
   destroying_ = true;
   static_cast<MenuHostRootView*>(GetRootView())->ClearSubmenu();
   Close();
+  // Since |submenu_| is not a child view it is necessary to notify its
+  // observers so that they can clean up the focus and drag and drop state.
+  View::ViewHierarchyChangedDetails details(false, NULL, submenu_, NULL);
+  ViewHierarchyChanged(details);

[sky, 2014/03/27 21:40:43]

I think this is a deficiency in how focus is cleaning things up and you
shouldn't work around it like this.

[varkha, 2014/03/27 22:05:10]

In this case the menu does not have focus (the menu is dropped down by the drag
over it, not by a click) and the focus can be anywhere else - even in a
different instance. The crash happens in DropHelper::NotifyDragExit() because
the DropHelper::target_view_ (of the SubmenuView class) is still not NULL but
has been destroyed when the menu was closed and failed to notify the Widget.
Should we call NativeWidgetPrivate::ViewRemoved in some other code path?

[sky, 2014/03/27 23:31:28]

Isn't this happening because SubmenuView is client owned so that when the
RootView is deleted no notification is sent for the SubmenuView?

 }
 
 void MenuHost::SetMenuHostBounds(const gfx::Rect& bounds) {