Implement MD specs for non-tabbed windows in Ash

chrome/browser/ui/browser_browsertest.cc

Index: chrome/browser/ui/browser_browsertest.cc
diff --git a/chrome/browser/ui/browser_browsertest.cc b/chrome/browser/ui/browser_browsertest.cc
index 9eb6b54f7b88848b4a3f426e14c5dec9d8bebd4d..b89102554eb67a63bf90f1bd306fe22c0c0da106 100644
--- a/chrome/browser/ui/browser_browsertest.cc
+++ b/chrome/browser/ui/browser_browsertest.cc
@@ -3224,7 +3224,11 @@ IN_PROC_BROWSER_TEST_F(BrowserTest, TestPopupBounds) {
     // Minimum size that a popup window should have appended to its height when
     // drawn (popup window bounds are for the content, not the window). This is
     // the size of the toolbar on views platforms.
+#if defined(OS_CHROMEOS)
+    const int minimum_popup_padding = 27;
+#else
     const int minimum_popup_padding = 29;
+#endif  // defined(OS_CHROMEOS)

[Peter Kasting, 2016/02/05 22:10:24]

Rather than ifdef this, let's either convert this hardcoded constant to some
kind of calculation that reflects what the real layout code actually does, or
remove it entirely.

Better yet, since the test is trying to ensure that the window is sized such
that the content area size is correct, maybe instead of trying to calculate the
total window height, we should modify the test to just ask for the actual
content area size within the window, and ensure it matches exactly.

[tdanderson, 2016/02/08 19:36:44]

I'm not sure how to do this. Querying browser->window()->GetContentsSize()
inside this test gives me 126*86, which doesn't make sense given that we've set
the initial bounds to 100*122. Based on the comment "initial height is content
height" I would have expected GetContentsSize() to give me 100*122.

[Peter Kasting, 2016/02/08 23:18:19]

You might want to check that this isn't a legitimate bug.  Perhaps we're not
actually creating popup windows with the correct contents size on request.

Another possibility is that we changed the meaning of the initial bounds param
to be the outer bounds instead of the inner bounds and the test is out of date.

Regardless, it sounds like we should understand why this is happening so we can
fix correctly.

[tdanderson, 2016/02/09 20:18:14]

During layout, BrowserView is reporting its own bounds as 126*149 and then
determines that the bounds of its contents is 126*86. So you're right that it
looks as though there is a legitimate bug here when params.initial_bounds is
used. After spending some more time I have not yet been successful in finding
the root cause - can we keep this test as-is for now and investigate the bug as
a separate issue?

 
     // Creates an untrusted popup window and asserts that the eventual height is
     // padded with the toolbar and title bar height (initial height is content