Description: Replace layout constants in chrome/browser/extensions and chrome/browser/first_run

chrome/browser/first_run/try_chrome_dialog_view_browsertest.cc

Index: chrome/browser/first_run/try_chrome_dialog_view_browsertest.cc
diff --git a/chrome/browser/first_run/try_chrome_dialog_view_browsertest.cc b/chrome/browser/first_run/try_chrome_dialog_view_browsertest.cc
index 7cfa862658e5780dbe81452076b308ebee6949a3..d2baa0e65ad7b76be2a9495e30c29a7c3eaca576 100644
--- a/chrome/browser/first_run/try_chrome_dialog_view_browsertest.cc
+++ b/chrome/browser/first_run/try_chrome_dialog_view_browsertest.cc
@@ -4,9 +4,11 @@
 
 #include "base/command_line.h"
 #include "build/build_config.h"
+#include "chrome/browser/ui/test/test_browser_dialog.h"
 #include "chrome/common/chrome_result_codes.h"
 #include "chrome/common/chrome_switches.h"
 #include "chrome/test/base/in_process_browser_test.h"
+#include "ui/base/ui_base_switches.h"
 
 // Unfortunately, this needs to be Windows only for now. Even though this test
 // is meant to exercise code that is for Windows only, it is a good general
@@ -16,6 +18,7 @@
 // will be improved to support this so we can get coverage on other platforms.
 // See http://crbug.com/45115 for details.
 #if defined(OS_WIN)
+#include "chrome/browser/ui/views/try_chrome_dialog_view.h"
 
 // By passing kTryChromeAgain with a magic value > 10000 we cause Chrome
 // to exit fairly early.
@@ -55,4 +58,33 @@ protected:
 // only makes the problem worse.
 IN_PROC_BROWSER_TEST_F(TryChromeDialogBrowserTest, ToastCrasher) {}
 
+// Helper class to display the TryChromeDialog for testing.
+class TryChromeDialogTest : public DialogBrowserTest {
+ public:
+  TryChromeDialogTest() {}
+
+  static void SetActiveModalDialog(gfx::NativeWindow active_dialog) {}
+
+  // DialogBrowserTest:
+  void ShowDialog(const std::string& name) override {
+    TryChromeDialogView::Show(
+        1000, base::Bind(&TryChromeDialogTest::SetActiveModalDialog));

[Peter Kasting, 2017/04/27 01:08:05]

It looks to me like instead of passing 1000 here, we want to provide several
different InvokeDialog cases below which invoke all the different flavors of
this dialog?  But it's not clear what "all those flavors" are.  I'm confused by
the flavors code.  It seems like there ought to be some kind of flavors enum. 
Also boo for "flavors" being passed in as a size_t but then silently truncated
to int to pass to a later function... but that's a pre-existing bug, not your
fault.

[ananta, 2017/04/27 01:29:52]

Yeah. Sorry about that. I was chatting with Greg. He said 0 works for him. I
ended up typing 1000 without thinking here. In any case I will add the other
flavors once the dialog starts showing up.

+  }
+
+  // content::BrowserTestBase:
+  void SetUpCommandLine(base::CommandLine* command_line) override {
+    command_line->AppendSwitch(switches::kExtendMdToSecondaryUi);
+  }
+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(TryChromeDialogTest);
+};
+
+// Test that calls ShowDialog("default"). Interactive when run via
+// browser_tests --gtest_filter=BrowserDialogTest.Invoke --interactive
+// --dialog=TryChromeDialogTest.InvokeDialog_default

[Peter Kasting, 2017/04/27 01:08:05]

Nit: Looks like most other test files omit this comment, so I would here too.

[ananta, 2017/04/27 01:29:52]

Done.

+IN_PROC_BROWSER_TEST_F(TryChromeDialogTest, InvokeDialog_default) {
+  RunDialog();
+}
+
 #endif  // defined(OS_WIN)