Allows menu host windows to be enumerated in DragTargetWindowFinder

ui/views/corewm/desktop_capture_controller_unittest.cc

Index: ui/views/corewm/desktop_capture_controller_unittest.cc
diff --git a/ui/views/corewm/desktop_capture_controller_unittest.cc b/ui/views/corewm/desktop_capture_controller_unittest.cc
index ad6d849e03ebb985bf39d3aca62f34bf698e441f..8807aafdd6eb322ffccc1993fd2ae12f860e2417 100644
--- a/ui/views/corewm/desktop_capture_controller_unittest.cc
+++ b/ui/views/corewm/desktop_capture_controller_unittest.cc
@@ -101,6 +101,7 @@ TEST_F(DesktopCaptureControllerTest, ResetMouseHandlers) {
   EXPECT_TRUE(w1_dispatcher->mouse_pressed_handler() == NULL);
   EXPECT_TRUE(w1_dispatcher->mouse_moved_handler() == NULL);
   w2->ReleaseCapture();
+  RunPendingMessages();

[varkha, 2014/03/26 00:15:53]

This test was failing because all the windows were created and destroyed before
the message loop had a chance to run and the messages were sent about windows
that no longer existed. I don't think this omission was intentional.

[sadrul, 2014/03/26 18:01:07]

I believe some tests run this in the TearDown() override, so each test doesn't
have to remember to do this. Perhaps it makes sense here too?

[varkha, 2014/03/27 04:48:13]

The problem is that w1/w2 get destroyed when exiting this method and that causes
the trouble.

[sadrul, 2014/03/27 19:13:46]

I see. That sounds like a bug. It would be a good idea to file a bug for it, so
we can come back and get it fixed.

[varkha, 2014/03/27 20:05:29]

We discussed this offline a bit. If we do not call the RunPendingMessages then
after w1/w2 get destroyed, then what happens is: we create the window, then
destroy the window, then the create-notify event comes in the next message-loop
iteration, then we get BadWindow error because the window has already been
destroyed. So it doesn't sound like this is something we can do much about
(other than fixing the test).

 }
 
 // Tests aura::Window capture and whether gesture events are sent to the window