[merge-m56] [mac] Disable usage of full size content view.

[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)

Committed: https://chromium.googlesource.com/chromium/src/+/216808010798a1d831de2b9dada85589c6e2918e

[tapted, 2016-11-23 22:58:36]

Description was changed from

==========
[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)
==========

to

==========
[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)

Committed:
https://chromium.googlesource.com/chromium/src/+/216808010798a1d831de2b9dada8...
==========

[tapted, 2016-11-23 22:58:38]

Committed patchset #1 (id:1) manually as
216808010798a1d831de2b9dada85589c6e2918e.