In random adventures through documentation, it looks like on 10.10 there's a way to resolve this without using NSTitlebarAccessoryViewController. This might allow it to be deployed without a big divergence in codepaths for the 10.9 flavour, and it's likely to be more tractable for mac_views_browser.

That is to use NSFullSizeContentViewWindowMask and -[NSWindow contentLayoutRect] - https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/#//apple_ref/occ/instp/NSWindow/contentLayoutRect

NSFullSizeContentViewWindowMask already appears in FullscreenLowPowerWindow (but it doesn't use contentLayoutRect).

I actually came across this while investigating rounded corners. There's some interesting stuff in Firefox for doing rounded corners without the "default" performance penalty of path-clipping and alpha blending - https://github.com/servo/servo/issues/9431#issuecomment-175570065 links to nsChildView::MaybeDrawRoundedCorners - https://dxr.mozilla.org/mozilla-central/rev/aa90f482e16db77cdb7dea84564ea1cbd8f7f6b3/widget/cocoa/nsChildView.mm#2034-2043

There's also some interesting stuff about rounded-corner peformance here - http://asyncdisplaykit.org/docs/corner-rounding.html (but for iOS).

(basically we need to take care that we don't "opt-out" of efficient corner rounding for the window. Also I think we already have some interesting tweaks to ensure the bottom corners remain rounded - the above stuff may link to ways we can improve on what we currently do, or otherwise ensure we don't regress performance if we move away from our existing hacks.

I've tried completely removing the following code from FullSizeContentView and everything still works on iOS 10.11:

// Our content view overlaps the window control buttons, so we must ensure
// it is positioned below the buttons.
NSView* superview = [chromeWindowView_ superview];
[chromeWindowView_ removeFromSuperview];
[superview addSubview:chromeWindowView_
           positioned:NSWindowBelow
           relativeTo:nil];

Maybe this code is unnecessary in 10.11 anymore. Or maybe I don't understand where "content view overlaps the window control buttons". Erik or Trent do you understand the purpose of moving chromeWindowView_ to another superview?

Ok, so removing that code makes window buttons hidden (unless the window is in foreground).

 Issue 575263  has been merged into this issue.

https://bugs.chromium.org/p/chromium/issues/detail?id=520373#c3. 
https://bugs.chromium.org/p/chromium/issues/detail?id=380412#c28

It looks like we want to use NSFullSizeContentViewWindowMask, introduced in 10.10, but it was broken as of two years ago.

Awhile back I tried just adding the fullscreen view to the window's contentView and didn't see any problems. I've worked up the following cl that makes this change:

https://codereview.chromium.org/2351183003

I don't know how well it works pre-10.11 so it's restricted to that and above. Let me know if you see any problems with it.

Jason, CL 2351183003 moves close/minimize/maximize buttons to the top and breaks experimental RTL (buttons remain on the left). I had CL similar to yours but could not move buttons properly.

Deleted: Normal.png 56.1 KB

	Normal.png 56.1 KB View Download

Deleted: RTL.png 48.8 KB

	RTL.png 48.8 KB View Download

That's a stinkin' bummer. I noticed the stoplights but I thought I confirmed that they were actually in the right place. I now remember this was an issue that erikchen@ also ran into. I'm going to see if I can salvage my cl.

I think with cl/2351183003 we have to use completely different approach for buttons moving. I found the way to do that in a test project (attached) and will try applying that hackery to your CL tomorrow. Jayson, if you have some time tomorrow, could you please take a loot at the attached WindowMask.zip project and check if that's even a reasonable direction to go.

In Chrome buttons are movable if moving code is inside dispatch_async block, but we also have to remove tracking area which highlights those buttons.

Deleted: WindowMask.zip 44.6 KB

WindowMask.zip 44.6 KB Download

You remove the tracking rect, but never add it back. I imagine that means that when you hover over one fo the buttons, they don't all highlight. I imagine it's possible to dig through AppKit and swizzle out the approrpiate methods to use a different position for the tracking rect, but I wasn't able to find it when I looked briefly a couple of years ago.

>> I imagine that means that when you hover over one fo the buttons, they don't all highlight. 
It may sound as counterintuitive, but buttons do highlight if I hover over them. It's probably an AppKit bug that they have an extra tracking rect which actually does nothing useful, but prevents moving the buttons.

In this sample project I found only one problem: the window is not draggable if you drag at the point where the buttons used to be. But that is a tiny area and we should be able to fix that.

I have code which fixes the buttons for non-fullscreen mode. Buttons can be moved using autolayout and tracking rect can be disabled via swizzling. There are still problems with fullscreen but those should also be solvable.

eugenebut@ - thank you for digging into this one. I thought my solution was the answer. Unfortunately there hasn't been enough time for me to try to get it all the way there.

Was trying to fix fullscreen widget buttons for "ExperimentalMacRTL" mode without realizing that they were always broken. I should have CL soon.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/42c6683729d8e049fdcc89e552bdcff5fb337227

commit 42c6683729d8e049fdcc89e552bdcff5fb337227
Author: eugenebut <eugenebut@chromium.org>
Date: Wed Oct 12 00:16:58 2016

[Mac] Avoid "adding unknown subview" warning.

Chrome Mac has added a subview above the window's content view, which
the Appkit warns about at runtime. Presumably, doing so may break in a
future macOS release. This cl adds Chrome's top-level subview to the
window's content view, which is what the Appkit wants. The change is
done only for macOS 10.11 and later.

Using correct view hierarchy breaks a few things which had to be fixed:

1.) Window buttons are now placed in NSToolbarContainerView which height
is 22 points and to move buttons down the whole NSToolbarContainerView
should be moved down. NSToolbarContainerView is not movable via
NSLayoutConstraints and simply resized every time its bounds changed.

2.) Window buttons are not movable anymore by changing their frame.
Their position is controlled by layout constraints received from
autoresizing mask and buttons can be moved via NSLayoutConstraints.

3.) The hight of browserFrameViewPaintHeight should be the same as tab strip
height in order to paint content area correctly.

4.) NSVisualEffect view for titlebar should be hidden in fullscreen.
With old view hierarchy NSVisualEffectView was moved offscreen for some reason.
Now it is always shown on the titlebar.

5.) Window does not update tracking area which highlights window
buttons when those buttons are moved (rdar://28535344). As a workaround
addTrackingArea: method is swizzled to prevent unnecessarily adding
an extra tracking area. Swizzling is necessary because OS does not
provide any signals that tracking area was updated (
NSViewDidUpdateTrackingAreasNotification is called before adding a
tracking area, not after).

6.) Windows w/o tab strip should not use NSFullSizeContentViewWindowMask
style mask, otherwise they will show up without toolbar.

7.) Tab should not allow moving window when dragged. This is done by
overriding _opaqueRectForWindowMoveWhenInTitlebar (AppKit follows the
same approach for NSButton, to prevent it from moving the window).

BUG= 605219 

Review-Url: https://codereview.chromium.org/2404783002
Cr-Commit-Position: refs/heads/master@{#424609}

[modify] https://crrev.com/42c6683729d8e049fdcc89e552bdcff5fb337227/base/mac/sdk_forward_declarations.h
[modify] https://crrev.com/42c6683729d8e049fdcc89e552bdcff5fb337227/chrome/browser/ui/cocoa/browser_window_layout.h
[modify] https://crrev.com/42c6683729d8e049fdcc89e552bdcff5fb337227/chrome/browser/ui/cocoa/browser_window_layout.mm
[modify] https://crrev.com/42c6683729d8e049fdcc89e552bdcff5fb337227/chrome/browser/ui/cocoa/framed_browser_window.h
[modify] https://crrev.com/42c6683729d8e049fdcc89e552bdcff5fb337227/chrome/browser/ui/cocoa/framed_browser_window.mm
[modify] https://crrev.com/42c6683729d8e049fdcc89e552bdcff5fb337227/chrome/browser/ui/cocoa/full_size_content_window.mm
[modify] https://crrev.com/42c6683729d8e049fdcc89e552bdcff5fb337227/chrome/browser/ui/cocoa/tabs/tab_strip_controller.mm
[modify] https://crrev.com/42c6683729d8e049fdcc89e552bdcff5fb337227/chrome/browser/ui/cocoa/tabs/tab_strip_view.mm
[modify] https://crrev.com/42c6683729d8e049fdcc89e552bdcff5fb337227/chrome/browser/ui/cocoa/tabs/tab_view.mm
[modify] https://crrev.com/42c6683729d8e049fdcc89e552bdcff5fb337227/chrome/browser/ui/cocoa/tabs/tab_window_controller.h
[modify] https://crrev.com/42c6683729d8e049fdcc89e552bdcff5fb337227/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1bee8df0bab836996dbdddd4e6817f11f3bae320

commit 1bee8df0bab836996dbdddd4e6817f11f3bae320
Author: tapted <tapted@chromium.org>
Date: Wed Oct 12 07:11:27 2016

Mac: Fix SDK 10.11 build error from r424609.

BUG= 605219 
TBR=eugenebut@chromium.org

Review-Url: https://codereview.chromium.org/2416513002
Cr-Commit-Position: refs/heads/master@{#424685}

[modify] https://crrev.com/1bee8df0bab836996dbdddd4e6817f11f3bae320/base/mac/sdk_forward_declarations.h
[modify] https://crrev.com/1bee8df0bab836996dbdddd4e6817f11f3bae320/chrome/browser/ui/cocoa/framed_browser_window.mm

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ba302109b0fafb5517c6ae29f5ae47735755c7da

commit ba302109b0fafb5517c6ae29f5ae47735755c7da
Author: eugenebut <eugenebut@chromium.org>
Date: Wed Oct 12 23:13:13 2016

[mac] Fixed window buttons positioning on Sierra.

Set buttons' bottomAnchor to superview bottomAnchor.

BUG= 655185 , 605219 

Review-Url: https://codereview.chromium.org/2412903003
Cr-Commit-Position: refs/heads/master@{#424900}

[modify] https://crrev.com/ba302109b0fafb5517c6ae29f5ae47735755c7da/base/mac/sdk_forward_declarations.h
[modify] https://crrev.com/ba302109b0fafb5517c6ae29f5ae47735755c7da/chrome/browser/ui/cocoa/framed_browser_window.mm

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0bd2a26b4420c4d4abb0f1101111e16c8f65c91c

commit 0bd2a26b4420c4d4abb0f1101111e16c8f65c91c
Author: eugenebut <eugenebut@chromium.org>
Date: Fri Oct 14 00:10:40 2016

[mac] Fixed FramedBrowserWindowTest.WindowWidgetLocation.

- call [window_ layoutIfNeeded] to update buttons position, which
   is controlled by layout constraints
- use window coordinates for verifying button locations

BUG= 655112 ,  605219 
TBR=tapted@chromium.org

Review-Url: https://codereview.chromium.org/2418703002
Cr-Commit-Position: refs/heads/master@{#425211}

[modify] https://crrev.com/0bd2a26b4420c4d4abb0f1101111e16c8f65c91c/chrome/browser/ui/cocoa/framed_browser_window_unittest.mm

 Issue 659154  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fd7cfb578fb058ee68c19051fb1ecd564b563f73

commit fd7cfb578fb058ee68c19051fb1ecd564b563f73
Author: tapted <tapted@chromium.org>
Date: Mon Nov 21 21:40:25 2016

[mac] Disable usage of full size content view.

Usually AppKit gives the contentView of a framed NSWindow an
NSThemeFrame as its superview. For a long time, Chrome has hacked around
this requirement, so we have more control over the frame layout. We
would instead add our contentView as a sibling of NSThemeFrame. But
AppKit warns, "NSWindow warning: adding an unknown subview" when we do
this.

In r424609 we started using NSFullSizeContentViewWindowMask to avoid the
warning. However, NSThemeFrame uses autolayout for the "traffic
light" buttons.

The prevailing theory is that adding the browser view hierarchy as a
subview of NSThemeFrame (rather than a sibling) we are unexpectedly
increasing the exposure that the browser view layout has to autolayout;
layout constraints and the constraint resolution alogithm. This resulted
in some known performance and layout regressions (fixed in r427290 and
r432024).

There's concern of additional, yet unknown regressions. So we want to
revert to the old ways for m56 so there is time for additional analysis.

BUG= 666415 ,  605219 

Review-Url: https://codereview.chromium.org/2521453002
Cr-Commit-Position: refs/heads/master@{#433658}

[modify] https://crrev.com/fd7cfb578fb058ee68c19051fb1ecd564b563f73/chrome/browser/ui/cocoa/browser_window_layout.mm

Making available again, since the fix is reverted.

> I'm starting to work on this. Quick question: why was it only enabled for 10.11+ if NSWindowStyleMaskFullSizeContentView is supported on 10.10+?

I'm not sure if it was a deliberate decision. It's likely we simply didn't have a 10.10 machine to test with, and didn't want to risk rolling it out there until it was well-tested on 10.11.

(oops data race - that was in response to sdy's comment at  http://crbug.com/666415#c9 )

I'm going to move any Auto Layout-specific blockers over to  issue 695577 .

This was 10.11+ because 10.10 did not have view hierarchy warning and I did not have machine to test on older version.

This is now high priority for High Sierra, and the main problems are  Issue 655112  and  Issue 665787 .

I have a CL up which stops adding views to the root view and changes how Chrome positions the window buttons. Feel free to read/comment:

https://chromium-review.googlesource.com/c/562603/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/45f7994fbcf0e40e02e4c4823a07b9b6ef28a325

commit 45f7994fbcf0e40e02e4c4823a07b9b6ef28a325
Author: Sidney San Martín <sdy@chromium.org>
Date: Tue Jul 11 07:05:57 2017

Enable ShouldUseFullSizeContentView().

Also fixes the known issues with enabling it:

- crbug/665787: The tab background view was added in front of the content and
  blocked interaction with the top of the scroll bar when the toolbar was
  hidden. It's now inserted behind the content, like before.

- crbug/655112: FramedBrowserWindowTest.DoesHideTitle took screenshots of the
  frame view, which gets drawn using a different (layer-backed?) path when
  NSFullSizeContentViewWindowMask is on. The test now calls -[CATransaction
  flush] before taking each screenshot, and uses a different API to screenshot
  the whole window instead of trying to grab just the frame view by accessing
  the content view's superview.

Bug:  605219 ,  655112 ,  665787 ,  730679 ,  734713 ,  737206 
Change-Id: Id78c21aff6748e02fd4b3e461c77ef9f7454d744
Reviewed-on: https://chromium-review.googlesource.com/566030
Commit-Queue: Sidney San Martin <sdy@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485544}
[modify] https://crrev.com/45f7994fbcf0e40e02e4c4823a07b9b6ef28a325/chrome/browser/ui/cocoa/browser_window_layout.mm
[modify] https://crrev.com/45f7994fbcf0e40e02e4c4823a07b9b6ef28a325/chrome/browser/ui/cocoa/framed_browser_window_unittest.mm
[modify] https://crrev.com/45f7994fbcf0e40e02e4c4823a07b9b6ef28a325/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/685e99063e6bac1d4417829ec3b6abdcb918caf6

commit 685e99063e6bac1d4417829ec3b6abdcb918caf6
Author: Keishi Hattori <keishi@chromium.org>
Date: Tue Jul 11 08:55:01 2017

Revert "Enable ShouldUseFullSizeContentView()."

This reverts commit 45f7994fbcf0e40e02e4c4823a07b9b6ef28a325.

Reason for revert: Broke BrowserWindowControllerTest.UsesAutoLayout

Original change's description:
> Enable ShouldUseFullSizeContentView().
> 
> Also fixes the known issues with enabling it:
> 
> - crbug/665787: The tab background view was added in front of the content and
>   blocked interaction with the top of the scroll bar when the toolbar was
>   hidden. It's now inserted behind the content, like before.
> 
> - crbug/655112: FramedBrowserWindowTest.DoesHideTitle took screenshots of the
>   frame view, which gets drawn using a different (layer-backed?) path when
>   NSFullSizeContentViewWindowMask is on. The test now calls -[CATransaction
>   flush] before taking each screenshot, and uses a different API to screenshot
>   the whole window instead of trying to grab just the frame view by accessing
>   the content view's superview.
> 
> Bug:  605219 ,  655112 ,  665787 ,  730679 ,  734713 ,  737206 
> Change-Id: Id78c21aff6748e02fd4b3e461c77ef9f7454d744
> Reviewed-on: https://chromium-review.googlesource.com/566030
> Commit-Queue: Sidney San Martin <sdy@chromium.org>
> Reviewed-by: Trent Apted <tapted@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#485544}

TBR=tapted@chromium.org,shrike@chromium.org,sdy@chromium.org

Change-Id: I00b73bc5d2d5607736ddc81b9ae81ec65527ebad
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  605219 ,  655112 ,  665787 ,  730679 ,  734713 ,  737206 
Reviewed-on: https://chromium-review.googlesource.com/566898
Reviewed-by: Keishi Hattori <keishi@chromium.org>
Commit-Queue: Keishi Hattori <keishi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485564}
[modify] https://crrev.com/685e99063e6bac1d4417829ec3b6abdcb918caf6/chrome/browser/ui/cocoa/browser_window_layout.mm
[modify] https://crrev.com/685e99063e6bac1d4417829ec3b6abdcb918caf6/chrome/browser/ui/cocoa/framed_browser_window_unittest.mm
[modify] https://crrev.com/685e99063e6bac1d4417829ec3b6abdcb918caf6/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a20a025fb10592190b5b3bc90fd627c45c76676a

commit a20a025fb10592190b5b3bc90fd627c45c76676a
Author: Sidney San Martín <sdy@chromium.org>
Date: Tue Jul 11 18:39:06 2017

Enable ShouldUseFullSizeContentView().

Also fixes the known issues with enabling it:

- crbug/665787: The tab background view was added in front of the content and
  blocked interaction with the top of the scroll bar when the toolbar was
  hidden. It's now inserted behind the content, like before.

- crbug/655112: FramedBrowserWindowTest.DoesHideTitle took screenshots of the
  frame view, which gets drawn using a different (layer-backed?) path when
  NSFullSizeContentViewWindowMask is on. The test now calls -[CATransaction
  flush] before taking each screenshot, and uses a different API to screenshot
  the whole window instead of trying to grab just the frame view by accessing
  the content view's superview.

This is a re-land of r485544 (reverted in r485564) with a test fix for
BrowserWindowControllerTest.UsesAutoLayout.

Bug:  605219 ,  655112 ,  665787 ,  730679 ,  734713 ,  737206 
Change-Id: I59c03e90b30613285df89a1b3694f36de3f1a7d8
Reviewed-on: https://chromium-review.googlesource.com/567205
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Sidney San Martin <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485682}
[modify] https://crrev.com/a20a025fb10592190b5b3bc90fd627c45c76676a/chrome/browser/ui/cocoa/browser_window_controller_unittest.mm
[modify] https://crrev.com/a20a025fb10592190b5b3bc90fd627c45c76676a/chrome/browser/ui/cocoa/browser_window_layout.mm
[modify] https://crrev.com/a20a025fb10592190b5b3bc90fd627c45c76676a/chrome/browser/ui/cocoa/framed_browser_window_unittest.mm
[modify] https://crrev.com/a20a025fb10592190b5b3bc90fd627c45c76676a/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/abd40204fe26341bbdc24cd475cb05dc850b10b6

commit abd40204fe26341bbdc24cd475cb05dc850b10b6
Author: Sidney San Martín <sdy@chromium.org>
Date: Tue Jul 11 22:40:32 2017

Add a Finch switch for ShouldUseFullSizeContentView().

Just in case :)

Bug:  605219 
Change-Id: Ia89712c1baa14fd932a8282d5b373f86bec7eeea
Reviewed-on: https://chromium-review.googlesource.com/566564
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Sidney San Martin <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485721}
[modify] https://crrev.com/abd40204fe26341bbdc24cd475cb05dc850b10b6/chrome/browser/ui/cocoa/browser_window_layout.mm
[modify] https://crrev.com/abd40204fe26341bbdc24cd475cb05dc850b10b6/chrome/common/chrome_features.cc
[modify] https://crrev.com/abd40204fe26341bbdc24cd475cb05dc850b10b6/chrome/common/chrome_features.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008

commit 1f71c6ec3d33ac53f8e2474fbfd9e6396f731008
Author: Sidney San Martín <sdy@chromium.org>
Date: Wed Aug 09 14:40:17 2017

Use a custom frame view class for browser windows.

This replaces swizzling and repositioning of views in the window frame (e.g.
moving the traffic light buttons to be centered in the tab strip). It's meant
to fail gracefully:

- The entry point is a single undocumented method (+[NSWindow
  frameViewClassForStyleMask:])
- On 10.10+, the overridden undocumented methods are all getters for simple
  values (BOOL, CGFloat, and NSPoint).
- The new code doesn't call any undocumented methods (other than super).

Window frame customization is difficult to test in an automated way, but a
manual test looks roughly like this (I skip some tests on some OSs, e.g. I
didn't put Accessibility Inspector on each test system):

  - Launch Chrome.
  - Verify that everything looks generally right.
  - Verify that the window buttons are in the same place as shipping Chrome.
  - If NSVisualEffectView is available, verify that things look right when I
    move a window around behind the browser window.
  - Verify that the window buttons respond on hover.
  - Verify that the window buttons can be clicked.
  - Close the window, open a new one, repeat the above checks.
  - Resize the window, repeat the above checks.
  - Bring the window into and out of fullscreen a couple of times and verify
    that the animations look the same as the current ones.
  - Repeat the above with "Always Show Toolbar In Full Screen" turned on/off.
  - Open an Incognito window.
  - Verify that the inactive window buttons are visible.
  - Verify that the inactive window buttons respond on hover.
  - Verify that the inactive window buttons can be clicked, but don't bring the
    window to the front on mouse down.
  - Repeat all of the above checks for the incognito window.
  - On 10.9, pay special attention to the positions of the profile picker and
    fullscreen button.
  - Navigate here: data:text/html,<script>window.onclick=()=>window.open('',
    '', 'width: 100; height: 100');</script>
  - Click the page to open a popup window. Repeat all of the above checks.
  - Turn on VoiceOver. Verify that you can navigate to and activate the window
    buttons. Turn off VoiceOver.
  - Launch Accessibility Inspector. Click the crosshair button in the toolbar
    and verify that you can use the mouse to target the window buttons.
  - On newer OSs, launch Chrome in RTL: -NSForceRightToLeftWritingDirection YES
    -AppleTextDirection YES --force-ui-direction=rtl --enable-features=MacRTL
  - On 10.12+, verify that the window buttons are on the right side of the
    window.
  - Repeat for each of macOS 10.{9..13}.


Bug:  605219 ,  651287 
Change-Id: Iee9b3b03ad677255b5df50c26742551347d7d4d8
Reviewed-on: https://chromium-review.googlesource.com/562603
Reviewed-by: Trent Apted <tapted@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Reviewed-by: Jayson Adams <shrike@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#492972}
[modify] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/BUILD.gn
[modify] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/cocoa/browser_window_controller_private.mm
[modify] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/cocoa/browser_window_controller_unittest.mm
[modify] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/cocoa/browser_window_fullscreen_transition.mm
[modify] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/cocoa/chrome_browser_window.h
[delete] https://crrev.com/d5ea6ad9b7b5af521c634c6461227c619b6728a1/chrome/browser/ui/cocoa/custom_frame_view.h
[delete] https://crrev.com/d5ea6ad9b7b5af521c634c6461227c619b6728a1/chrome/browser/ui/cocoa/custom_frame_view.mm
[delete] https://crrev.com/d5ea6ad9b7b5af521c634c6461227c619b6728a1/chrome/browser/ui/cocoa/custom_frame_view_unittest.mm
[modify] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/cocoa/framed_browser_window.h
[modify] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/cocoa/framed_browser_window.mm
[modify] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/cocoa/framed_browser_window_unittest.mm
[delete] https://crrev.com/d5ea6ad9b7b5af521c634c6461227c619b6728a1/chrome/browser/ui/cocoa/full_size_content_window.h
[delete] https://crrev.com/d5ea6ad9b7b5af521c634c6461227c619b6728a1/chrome/browser/ui/cocoa/full_size_content_window.mm
[add] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/cocoa/tabbed_browser_window.h
[add] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/cocoa/tabbed_browser_window.mm
[add] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/cocoa/tabbed_browser_window_unittest.mm
[modify] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/browser/ui/cocoa/tabs/tab_window_controller.mm
[modify] https://crrev.com/1f71c6ec3d33ac53f8e2474fbfd9e6396f731008/chrome/test/BUILD.gn

The above CL landed in today's Canary, and Chrome should no longer be adding views to the window frame under any circumstances \o/.