Just set borders once when creating a views::LabelButton

chrome/browser/ui/views/bookmarks/bookmark_bar_view_test.cc

Index: chrome/browser/ui/views/bookmarks/bookmark_bar_view_test.cc
diff --git a/chrome/browser/ui/views/bookmarks/bookmark_bar_view_test.cc b/chrome/browser/ui/views/bookmarks/bookmark_bar_view_test.cc
index 3262df593f0a94ce6001257517e0d9e28ec48769..19dd3ebd7c1db5090fb8fe9aab80c44b6a77088a 100644
--- a/chrome/browser/ui/views/bookmarks/bookmark_bar_view_test.cc
+++ b/chrome/browser/ui/views/bookmarks/bookmark_bar_view_test.cc
@@ -287,6 +287,10 @@ class BookmarkBarViewEventTestBase : public ViewEventTestBase {
 
     AddTestData(CreateBigMenu());
 
+    // Create the Widget. This ensures the following calculation correctly

[msw, 2015/07/10 18:40:07]

Hmm, where does the view get added to the widget?

[tapted, 2015/07/13 07:41:21]

Yeah, this test harness is a bit crafty :). ViewEventTestBase is a
views::WidgetDelegate. super::SetUp() then does
Widget::CreateWindowWithContext(), allowing Widget::Init() to get a custom
ContentsView from the test harness at initialization-time.

So during Init(), BookmarkBarViewEventTestBase::CreateContentsView() returns
bb_view_, which is added as the RootView()'s descendant under its ContentsView.

This also means bb_view_ needs to be initialized before a call to 
ViewEventTestBase::SetUp();

Added a comment.

+    // applies borders which may be derived from the Widget's NativeTheme.
+    ViewEventTestBase::SetUp();

[msw, 2015/07/10 18:40:07]

nit: maybe call this at the top of the function?

[tapted, 2015/07/13 07:41:21]

(see above)

+
     // Calculate the preferred size so that one button doesn't fit, which
     // triggers the overflow button to appear. We have to do this incrementally
     // as there isn't a good way to determine the point at which the overflow
@@ -302,8 +306,7 @@ class BookmarkBarViewEventTestBase : public ViewEventTestBase {
       bb_view_->SetBounds(0, 0, bb_view_pref_.width(), bb_view_pref_.height());
       bb_view_->Layout();
     } while (GetBookmarkButton(6)->visible());
-
-    ViewEventTestBase::SetUp();
+    window_->SetSize(GetPreferredSize());

[msw, 2015/07/10 18:40:07]

why is this needed now?

[tapted, 2015/07/13 07:41:22]

(tl;dr "moved" this to the GetPreferredSize() test harness override)

I added this line because the "preferred size" reported by the test harness is
cached during SetUp(). So the calculation above that changed it had to be
applied explicitly.

(note this line actually wasn't quite right - it worked on DesktopLinux, but on
other platforms there were test failures because the mouse event to open the
menu would "miss" the window because Widget::SetSize() sets the frame size, but
GetPreferredSize() is for the client view, so the window was not tall enough.

Patchset 5 just fixes this line to include the frame view and has green runs)


But it had me asking: "does this mean the Widget might layout improperly during
Init". So I moved the max-width calculation to GetPreferredSize() to check (and
make this line obsolete). Again, the test harness is a bit tricky to follow...

Widget::Init() *does* call SetInitialBounds after adding the ContentView to the
hierarchy and calling OnNativeThemeChanged, etc. However, the test harness was
caching the preferred size too early. To fix, we can update ViewEventTestBase to
delegate the preferred size rather than cache it (Done in Patchset 6+)

   }
 
   void TearDown() override {