Make File-Picker modal on Linux

chrome/browser/ui/browser_focus_uitest.cc

Index: chrome/browser/ui/browser_focus_uitest.cc
diff --git a/chrome/browser/ui/browser_focus_uitest.cc b/chrome/browser/ui/browser_focus_uitest.cc
index 9421bed46b90843725760bf897757322f3477b46..0b7c6e26dbc5fd771b729bd2319bb1129ee8a6cf 100644
--- a/chrome/browser/ui/browser_focus_uitest.cc
+++ b/chrome/browser/ui/browser_focus_uitest.cc
@@ -7,6 +7,7 @@
 #include "base/format_macros.h"
 #include "base/message_loop/message_loop.h"
 #include "base/path_service.h"
+#include "base/run_loop.h"
 #include "base/strings/stringprintf.h"
 #include "base/strings/utf_string_conversions.h"
 #include "chrome/browser/chrome_notification_types.h"
@@ -238,6 +239,38 @@ IN_PROC_BROWSER_TEST_F(BrowserFocusTest, DISABLED_BrowsersRememberFocus) {
   ASSERT_TRUE(IsViewFocused(VIEW_ID_OMNIBOX));
 }
 
+// This test is only for Linux Desktop.
+#if defined(OS_LINUX) && !defined(OS_CHROMEOS) && defined(USE_AURA)

[msw, 2015/09/04 22:25:16]

Remove |&& defined(USE_AURA)| from here and similar instances below; no such
configuration exists, afaik.

[joone, 2015/09/10 23:55:38]

Done.

+#define MAYBE_BrowserDialogModalTest BrowserDialogModalTest
+#else
+#define MAYBE_BrowserDialogModalTest DISABLE_BrowserDialogModalTest

[msw, 2015/09/04 22:25:16]

"DISABLED_"

[joone, 2015/09/10 23:55:38]

Done.

+#endif
+IN_PROC_BROWSER_TEST_F(BrowserFocusTest, MAYBE_BrowserDialogModalTest) {
+  ASSERT_TRUE(ui_test_utils::BringBrowserWindowToFront(browser()));
+  const GURL url = embedded_test_server()->GetURL(kSimplePage);
+  ui_test_utils::NavigateToURL(browser(), url);
+  ASSERT_TRUE(browser()->window()->IsActive());
+
+  browser()->OpenFile();
+
+  // Insert a delay to wait until the file-picker is opened and gets focus.

[msw, 2015/09/04 22:25:17]

Is there a better way to do this? If the nested run loop's quit closure isn't
called because something is blocked, the test will hang until the harness
aborts, after maybe 20 minutes (I think). Consider using something like
ViewManagerTestBase::DoRunLoopWithTimeout; I also wonder if some intermediary
step might post another task amidst the opening of the dialog, so the nested run
loop might quit before the dialog is fully opened (but perhaps that's unlikely).
Maybe consider observing deactivation of the browser window?

[joone, 2015/09/10 23:55:38]

I added a timeout(1 sec).

+  base::RunLoop run_loop;
+  base::MessageLoop::current()->PostTask(
+        FROM_HERE, run_loop.QuitClosure());
+  run_loop.Run();
+
+  gfx::Rect rect = browser()->window()->GetBounds();

[msw, 2015/09/04 22:25:17]

Right after the run loop, do EXPECT_FALSE(browser()->window()->IsActive());

[joone, 2015/09/10 23:55:38]

Done.

+  ASSERT_TRUE(ui_test_utils::SendMouseMoveSync(gfx::Point(rect.x() + 1,

[msw, 2015/09/04 22:25:16]

nit: maybe use ClickOnView instead?

[joone, 2015/09/10 23:55:38]

Done.

+      rect.y() + 1)));
+  ASSERT_TRUE(ui_test_utils::SendMouseEventsSync(

[msw, 2015/09/04 22:25:16]

I wonder if (1) Perhaps the dialog will actually cover the visible bounds of the
browser window, so clicking there is actually focusing the dialog... (2) If
other methods of window switching/interaction would actually cause the browser
window to become active here (ie. can you also test BringBrowserWindowToFront,
ShowAndFocusNativeWindow, SendKeyPress*, and/or pressing something like
[Alt]+[Tab], etc.)

[joone, 2015/09/10 23:55:38]

Calling ClickOnView() may be able to fix this problem.

(2) If
Done.

+      ui_controls::LEFT, ui_controls::DOWN));
+  ASSERT_TRUE(ui_test_utils::SendMouseEventsSync(
+      ui_controls::LEFT, ui_controls::UP));
+
+  // The window should not get focus due to modal dialog.
+  EXPECT_FALSE(browser()->window()->IsActive());
+}
+
 // Tabs remember focus.
 // Disabled, http://crbug.com/62542.
 IN_PROC_BROWSER_TEST_F(BrowserFocusTest, DISABLED_TabsRememberFocus) {