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

Thanks for the fix.Is there a way to manually verify the bug?If yes, we can verify in latest canary.

Please request a merge to M56 if all looks good.It would be great to have everything set before build cut @3 PM Monday 11/28.

Tested in 57.0.2929.4 canary - looks good. Didn't spot any regressions and verified that the repro steps for in  Issue 667698  (discovered shortly after r433658 landed) no longer manifest.

Requesting merge of r433658 to m56.

Your change meets the bar and is auto-approved for M56 (branch: 2924)

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

commit 216808010798a1d831de2b9dada85589c6e2918e
Author: Trent Apted <tapted@chromium.org>
Date: Wed Nov 23 22:53:36 2016

[merge-m56] [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 

Review-Url: https://codereview.chromium.org/2521453002
Cr-Commit-Position: refs/heads/master@{#433658}
(cherry picked from commit fd7cfb578fb058ee68c19051fb1ecd564b563f73)

Review URL: https://codereview.chromium.org/2523323002 .

Cr-Commit-Position: refs/branch-heads/2924@{#85}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

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

Tested the fix on Mac 10.11.6 using chrome version 56.0.2924.5 with the steps mentioned in  Issue 667698 .
Able to resize the window from RHS after adding the extension.
Please find the attched screen cast for the same.

Adding TE-Verified labels.

Deleted: 666415.mp4 1.6 MB

	666415.mp4 1.6 MB View Download

 Issue 665787  has been merged into this issue.

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

Sorry, wrong bug. I'll repost on  issue 605219  if I don't see anything there :).