mac: Fix tab dragging visual bug in Yosemite.

chrome/browser/ui/cocoa/tabs/tab_window_controller.mm

Index: chrome/browser/ui/cocoa/tabs/tab_window_controller.mm
diff --git a/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm b/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm
index c6dfa624f0ef37063166cb708b2cc7b1306d5482..f0617c45ea92d302acca9e33a4f11a631a9754c4 100644
--- a/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm
+++ b/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm
@@ -57,11 +57,17 @@
   if ((self = [super initWithWindow:window])) {
     [[self window] setDelegate:self];
 
+    chromeContentView_.reset(
+        [[NSView alloc] initWithFrame:NSMakeRect(0, 0, 750, 600)]);
+    [chromeContentView_
+        setAutoresizingMask:NSViewWidthSizable | NSViewHeightSizable];
+    [[[self window] contentView] addSubview:chromeContentView_];
+
     tabContentArea_.reset([[FastResizeView alloc] initWithFrame:
         NSMakeRect(0, 0, 750, 600)]);

[Andre, 2014/07/11 00:57:11]

initWithFrame:[chromeContentView_ bounds]
to avoid repeating magic numbers.

[erikchen, 2014/07/11 01:17:43]

Done.

     [tabContentArea_ setAutoresizingMask:NSViewWidthSizable |
                                          NSViewHeightSizable];
-    [[[self window] contentView] addSubview:tabContentArea_];
+    [self.chromeContentView addSubview:tabContentArea_];

[Andre, 2014/07/11 00:57:11]

nit: self.chromeContentView -> chromeContentView_ to be consistent with
surrounding code.

[erikchen, 2014/07/11 01:17:43]

Done.

[Scott Hess - ex-Googler, 2014/07/11 18:08:34]

There are a couple other places in the patch which are using
self.chromeContentView and should be converted to chromeContentView_.

[erikchen, 2014/07/11 20:48:04]

That's not possible for most of the classes, since chromeContentView_ is a
private property. I also prefer to use self.'property' notation for properties,
since that's the entire point of having the property abstraction. I changed it
here only because there's a light taboo against using 'self' in the designated
initializer.

[Scott Hess - ex-Googler, 2014/07/11 21:10:52]

There are so few cases of self.accessor in the codebase that I'm inclined to
think they are mistakes rather than intentional style allowances - but at this
point I think it doesn't matter.  As far as your preferences come into play ...
it's nice to have preferences, but given that we have a billion Chromium
developers, please use style A if the code you're working in uses style A,
unless there's been a style-overlord ruling that things should be converted to
style B.

The style guide says "Whenever practical" WRT using accessors in the designated
initializer or -dealloc, for good reason.  I wouldn't say it's a light taboo.

[erikchen, 2014/07/11 21:18:19]

Fair points. Got it.

 
     tabStripView_.reset([[TabStripView alloc] initWithFrame:
         NSMakeRect(0, 0, 750, 37)]);
@@ -81,6 +87,10 @@
   return tabContentArea_;
 }
 
+- (NSView*)chromeContentView {
+  return chromeContentView_;
+}
+
 // Add the top tab strop to the window, above the content box and add it to the
 // view hierarchy as a sibling of the content view so it can overlap with the
 // window frame.
@@ -127,7 +137,7 @@
     [overlayWindow_ setOpaque:NO];
     [overlayWindow_ setDelegate:self];
 
-    originalContentView_ = [window contentView];
+    originalContentView_ = self.chromeContentView;
     [window addChildWindow:overlayWindow_ ordered:NSWindowAbove];
 
     // Explicitly set the responder to be nil here (for restoring later).
@@ -153,7 +163,9 @@
     // places. The TabStripView always needs to be in front of the window's
     // content view and therefore it should always be added after the content
     // view is set.
-    [window setContentView:originalContentView_];
+    [[window contentView] addSubview:originalContentView_
+                          positioned:NSWindowBelow
+                          relativeTo:nil];
     [[window cr_windowView] addSubview:[self tabStripView]];
     [[window cr_windowView] updateTrackingAreas];