[Mac] Lay out the browser window when adding the download shelf.

[Mac] Lay out the browser window when adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being shown (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, BrowserWindowController doesn't lay out the window after adding
the download shelf. When the download shelf is shown, -layoutSubviews is called
via -resizeView:newHeight:, but in some cases, like a quick extension install,
it's added and left hidden. In that case, the shelf will be positioned like
this (but you can't see it, since it's hidden and has zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
window is wider than the shelf when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf is made
narrower and eventually reaches a minimum size.

If the user makes the window even smaller, one of two things will happen
depending on whether Auto Layout is handling the window:

- No Auto Layout: the layout breaks (but the user never sees it happen, because
  -layoutSubviews fixes it up if the download shelf is shown).

- Auto Layout: The layout engine treats the fixed margin as a constraint and
  prevents the window from becoming any narrower.

The next time -[BrowserWindowController layoutSubviews] runs, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
Review-Url: https://codereview.chromium.org/2742813003
Cr-Commit-Position: refs/heads/master@{#457055}
Committed: https://chromium.googlesource.com/chromium/src/+/d06b1c5641ca1022fd4165ea46d8295fb5a215b4

[Sidney San Martín, 2017-03-10 05:14:16]

The CQ bit was checked by sdy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-10 05:14:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Sidney San Martín, 2017-03-10 05:15:09]

Description was changed from

==========
[Mac] Lay out the browser window after adding the download shelf.

This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

Before this CL, the downloads shelf may be added without the window performing
layout. In that case, the download shelf will be positioned like this (but
hidden and with zero height):

   /---------------------------------------\
   |---------------------------------------|
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |---------------------------            |
   |                         ⨯|            |
   \---------------------------------------/

The shelf's autoresizing mask gives it flexible width but fixed margins. If
it's narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

Next step: only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

to

==========
[Mac] Lay out the browser window after adding the download shelf.

This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

Before this CL, the downloads shelf may be added without the window performing
layout. In that case, the download shelf will be positioned like this (but
hidden and with zero height):
       ╭───────────────────────────────────────╮
       ├───────────────────────────────────────┤
       │                                       │
       │                                       │
       │                                       │
       │                                       │
       │                                       │
       │                                       │
       │                                       │
       ├──────────────────────────┐            │
       │                         ⨯│            │
       ╰──────────────────────────┴────────────╯

The shelf's autoresizing mask gives it flexible width but fixed margins. If
it's narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

Next step: only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

[Sidney San Martín, 2017-03-10 05:15:42]

Description was changed from

==========
[Mac] Lay out the browser window after adding the download shelf.

This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

Before this CL, the downloads shelf may be added without the window performing
layout. In that case, the download shelf will be positioned like this (but
hidden and with zero height):
       ╭───────────────────────────────────────╮
       ├───────────────────────────────────────┤
       │                                       │
       │                                       │
       │                                       │
       │                                       │
       │                                       │
       │                                       │
       │                                       │
       ├──────────────────────────┐            │
       │                         ⨯│            │
       ╰──────────────────────────┴────────────╯

The shelf's autoresizing mask gives it flexible width but fixed margins. If
it's narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

Next step: only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

to

==========
[Mac] Lay out the browser window after adding the download shelf.

This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

Before this CL, the downloads shelf may be added without the window performing
layout. In that case, the download shelf will be positioned like this (but
hidden and with zero height):

   /---------------------------------------\
   |---------------------------------------|
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |---------------------------            |
   |                         x|            |
   \---------------------------------------/

The shelf's autoresizing mask gives it flexible width but fixed margins. If
it's narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

Next step: only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

[Sidney San Martín, 2017-03-10 05:17:19]

Description was changed from

==========
[Mac] Lay out the browser window after adding the download shelf.

This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

Before this CL, the downloads shelf may be added without the window performing
layout. In that case, the download shelf will be positioned like this (but
hidden and with zero height):

   /---------------------------------------\
   |---------------------------------------|
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |---------------------------            |
   |                         x|            |
   \---------------------------------------/

The shelf's autoresizing mask gives it flexible width but fixed margins. If
it's narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

Next step: only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

to

==========
[Mac] Lay out the browser window after adding the download shelf.

This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

Before this CL, the downloads shelf may be added without the window performing
layout. In that case, the download shelf will be positioned like this (but
hidden and with zero height):

   /---------------------------------------\
   |---------------------------------------|
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |---------------------------            |
   |                         x|            |
   \---------------------------------------/

The shelf's autoresizing mask gives it flexible width but fixed margins. If
it's narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

Next: only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

[Sidney San Martín, 2017-03-10 05:20:50]

sdy@chromium.org changed reviewers:
+ tapted@chromium.org

[Sidney San Martín, 2017-03-10 05:20:50]

Auto Layout bugfix! PTAL.

[commit-bot: I haz the power, 2017-03-10 05:38:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-10 05:38:13]

Dry run: This issue passed the CQ dry run.

[tapted, 2017-03-10 07:22:28]

lgtm

https://codereview.chromium.org/2742813003/diff/1/chrome/browser/ui/cocoa/bro...
File chrome/browser/ui/cocoa/browser_window_controller_unittest.mm (right):

https://codereview.chromium.org/2742813003/diff/1/chrome/browser/ui/cocoa/bro...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:176: NSWindow*
cocoaWindow = browser_window->GetNativeWindow();
nit: cocoa_window

(I realise other TEST_F use cocoaWindow but I use the "between @foo/@end" rule
to pick camelCase, and the style should at lease be consistent with
browser_window above)

alternatively (perhaps better) I guess

BrowserWindowController* controller =
    [BrowserWindowController
browserWindowControllerForWindow:browser_window->GetNativeWindow()];

will avoid the static_cast as well as the temporary :)

https://codereview.chromium.org/2742813003/diff/1/chrome/browser/ui/cocoa/bro...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:180: [controller
createAndAddDownloadShelf];
or perhaps a better alternative, you could just

EXPECT_TRUE(browser_window->GetDownloadShelf());

which guarantees a createAndAddDownloadShelf is called.

Also do we want something like

EXPECT_TRUE(browser_window=>IsDownloadShelfVisible()); ?

https://codereview.chromium.org/2742813003/diff/1/chrome/browser/ui/cocoa/bro...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:182:
browser_window->SetBounds(gfx::Rect(0, 0, 50, 50));
Is this subject to autolayout constraints?

If it is, you could comment before; something like

// BrowserWindowCocoa::SetBounds() uses -enforceMinWindowSize: to ensure the
bounds
// satisfy the window's autolayout constraints.

But -enforceMinWindowSize: just asks for the NSWindow's min/max size properties
-- I'm not sure (and think:not) whether those properties account for layout
calculations.

Then SetBounds just uses [NSWindow setFrame:] which I think doesn't apply
constraints the same way as a user-initiated resize.

E.g. does the test still pass with [self layoutSubviews]; removed?

Maybe there's a method you can call directly on
browser_window->GetNativeWindow() which sets the frame size subject to layout
constraints?

https://codereview.chromium.org/2742813003/diff/1/chrome/browser/ui/cocoa/bro...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:185:
EXPECT_EQ(272, bounds.height());
400 / 272 are magic numbers. At the very least they need to be drawn up into a
constant at the top of the test file and shared with other tests.

But a lot more appropriate would be to declare something in
browser_window_controller.h so that -[BrowserWindowController
initWithBrowser:..] can use them as well.

[tapted, 2017-03-10 07:26:01]

and uhh.. not lgtm yet.

for some awful reason the "Publish+Mail Comments" URL now performs an initial
layout for me with the sidebar initially wide enough such that the "Publish"
button is in exactly the same place that the "Quick LGTM" button will be a
split-second later when it decides to perform a re-layout.

Layout().... it is tormenting us on multiple levels now :p

[Sidney San Martín, 2017-03-10 15:42:17]

Patchset #2 (id:20001) has been deleted

[Sidney San Martín, 2017-03-10 21:47:52]

The CQ bit was checked by sdy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-10 21:48:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Sidney San Martín, 2017-03-10 22:02:41]

Description was changed from

==========
[Mac] Lay out the browser window after adding the download shelf.

This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

Before this CL, the downloads shelf may be added without the window performing
layout. In that case, the download shelf will be positioned like this (but
hidden and with zero height):

   /---------------------------------------\
   |---------------------------------------|
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   |---------------------------            |
   |                         x|            |
   \---------------------------------------/

The shelf's autoresizing mask gives it flexible width but fixed margins. If
it's narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

Next: only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

to

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, the downloads shelf may be added without
BrowserWindowController performing layout. In that case, the download shelf
will be positioned like this (but hidden and with zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
shelf is narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future steps
Only keep the download shelf in the view hierarchy when it's visible.

BUG=667698, 695577
==========

[Sidney San Martín, 2017-03-10 22:03:14]

Description was changed from

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, the downloads shelf may be added without
BrowserWindowController performing layout. In that case, the download shelf
will be positioned like this (but hidden and with zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
shelf is narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future steps
Only keep the download shelf in the view hierarchy when it's visible.

BUG=667698, 695577
==========

to

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, the downloads shelf may be added without
BrowserWindowController performing layout. In that case, the download shelf
will be positioned like this (but hidden and with zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
shelf is narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future steps
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

[Sidney San Martín, 2017-03-10 22:03:28]

Description was changed from

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, the downloads shelf may be added without
BrowserWindowController performing layout. In that case, the download shelf
will be positioned like this (but hidden and with zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
shelf is narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future steps
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

to

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, the downloads shelf may be added without
BrowserWindowController performing layout. In that case, the download shelf
will be positioned like this (but hidden and with zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
shelf is narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

[Sidney San Martín, 2017-03-10 22:04:01]

Description was changed from

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being opened (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, the downloads shelf may be added without
BrowserWindowController performing layout. In that case, the download shelf
will be positioned like this (but hidden and with zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
shelf is narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

to

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary This fixes a regression when a browser window uses Auto Layout: if
the download shelf is added to the window without ever being shown (e.g. when
installing an extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, the downloads shelf may be added without
BrowserWindowController performing layout. In that case, the download shelf
will be positioned like this (but hidden and with zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
shelf is narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

[Sidney San Martín, 2017-03-10 22:04:20]

Description was changed from

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary This fixes a regression when a browser window uses Auto Layout: if
the download shelf is added to the window without ever being shown (e.g. when
installing an extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, the downloads shelf may be added without
BrowserWindowController performing layout. In that case, the download shelf
will be positioned like this (but hidden and with zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
shelf is narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

to

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being shown (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, the downloads shelf may be added without
BrowserWindowController performing layout. In that case, the download shelf
will be positioned like this (but hidden and with zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
shelf is narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

[commit-bot: I haz the power, 2017-03-10 22:09:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-10 22:09:06]

Dry run: This issue passed the CQ dry run.

[Sidney San Martín, 2017-03-10 22:21:44]

Description was changed from

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being shown (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, the downloads shelf may be added without
BrowserWindowController performing layout. In that case, the download shelf
will be positioned like this (but hidden and with zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
shelf is narrower than the window when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf becomes
narrower and eventually reaches a minimum size, and Auto Layout enforces the
fixed margin by preventing the window from being made any smaller.

The next time -[BrowserWindowController layoutSubviews] is called, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

to

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being shown (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, BrowserWindowController doesn't lay out the window after adding
the download shelf. When the download shelf is shown, -layoutSubviews is called
via -resizeView:newHeight:, but in some cases, like a quick extension install,
it's added and left hidden. In that case, the shelf will be positioned like
this (but you can't see it, since it's hidden and has zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
window is wider than the shelf when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf is made
narrower and eventually reaches a minimum size.

If the user makes the window even smaller, one of two things will happen
depending on whether Auto Layout is handling the window:

- No Auto Layout: the layout breaks (but the user never sees it happen, because
  -layoutSubviews fixes it up if the download shelf is shown).

- Auto Layout: The layout engine treats the fixed margin as a constraint and
  prevents the window from becoming any narrower.

The next time -[BrowserWindowController layoutSubviews] runs, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

[Sidney San Martín, 2017-03-10 22:22:09]

Description was changed from

==========
[Mac] Lay out the browser window after adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being shown (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, BrowserWindowController doesn't lay out the window after adding
the download shelf. When the download shelf is shown, -layoutSubviews is called
via -resizeView:newHeight:, but in some cases, like a quick extension install,
it's added and left hidden. In that case, the shelf will be positioned like
this (but you can't see it, since it's hidden and has zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
window is wider than the shelf when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf is made
narrower and eventually reaches a minimum size.

If the user makes the window even smaller, one of two things will happen
depending on whether Auto Layout is handling the window:

- No Auto Layout: the layout breaks (but the user never sees it happen, because
  -layoutSubviews fixes it up if the download shelf is shown).

- Auto Layout: The layout engine treats the fixed margin as a constraint and
  prevents the window from becoming any narrower.

The next time -[BrowserWindowController layoutSubviews] runs, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

to

==========
[Mac] Lay out the browser window when adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being shown (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, BrowserWindowController doesn't lay out the window after adding
the download shelf. When the download shelf is shown, -layoutSubviews is called
via -resizeView:newHeight:, but in some cases, like a quick extension install,
it's added and left hidden. In that case, the shelf will be positioned like
this (but you can't see it, since it's hidden and has zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
window is wider than the shelf when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf is made
narrower and eventually reaches a minimum size.

If the user makes the window even smaller, one of two things will happen
depending on whether Auto Layout is handling the window:

- No Auto Layout: the layout breaks (but the user never sees it happen, because
  -layoutSubviews fixes it up if the download shelf is shown).

- Auto Layout: The layout engine treats the fixed margin as a constraint and
  prevents the window from becoming any narrower.

The next time -[BrowserWindowController layoutSubviews] runs, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

[Sidney San Martín, 2017-03-10 22:23:42]

PTAL

https://codereview.chromium.org/2742813003/diff/1/chrome/browser/ui/cocoa/bro...
File chrome/browser/ui/cocoa/browser_window_controller_unittest.mm (right):

https://codereview.chromium.org/2742813003/diff/1/chrome/browser/ui/cocoa/bro...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:176: NSWindow*
cocoaWindow = browser_window->GetNativeWindow();
On 2017/03/10 07:22:28, tapted wrote:
> nit: cocoa_window
> 
> (I realise other TEST_F use cocoaWindow but I use the "between @foo/@end" rule
> to pick camelCase, and the style should at lease be consistent with
> browser_window above)
> 
> alternatively (perhaps better) I guess
> 
> BrowserWindowController* controller =
>     [BrowserWindowController
> browserWindowControllerForWindow:browser_window->GetNativeWindow()];
> 
> will avoid the static_cast as well as the temporary :)

See below.

https://codereview.chromium.org/2742813003/diff/1/chrome/browser/ui/cocoa/bro...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:180: [controller
createAndAddDownloadShelf];
On 2017/03/10 07:22:28, tapted wrote:
> or perhaps a better alternative, you could just
> 
> EXPECT_TRUE(browser_window->GetDownloadShelf());
> 
> which guarantees a createAndAddDownloadShelf is called.

That's much nicer, thanks!

> Also do we want something like
> 
> EXPECT_TRUE(browser_window=>IsDownloadShelfVisible()); ?

Good idea. I added an EXPECT_FALSE — this bug only happens when the download
shelf is created without being shown.

https://codereview.chromium.org/2742813003/diff/1/chrome/browser/ui/cocoa/bro...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:182:
browser_window->SetBounds(gfx::Rect(0, 0, 50, 50));
On 2017/03/10 07:22:28, tapted wrote:
> Is this subject to autolayout constraints?
> 
> If it is, you could comment before; something like
> 
> // BrowserWindowCocoa::SetBounds() uses -enforceMinWindowSize: to ensure the
> bounds
> // satisfy the window's autolayout constraints.
> 
> But -enforceMinWindowSize: just asks for the NSWindow's min/max size
properties
> -- I'm not sure (and think:not) whether those properties account for layout
> calculations.
> 
> Then SetBounds just uses [NSWindow setFrame:] which I think doesn't apply
> constraints the same way as a user-initiated resize.

[NSWindow setFrame:] marks the window as needing layout, and the next layout
pass will definitely adjust the size of the window to satisfy constraints.

Something interesting: SetBounds calls -[NSWindow setFrame:… display:YES]. When
linking against the 10.10 SDK, the display:YES causes layout to happen
immediately, and potentially change the window's frame. But, when linking
against a newer SDK, it waits until the current CATransaction commits. In a test
app, I can initially read back the frame as I set it, then it changes after the
commit. I added a preemptive -layoutIfNeeded and comment.

> E.g. does the test still pass with [self layoutSubviews]; removed?

The test passes now, but it won't pass with Auto Layout in effect. I added a
demo patch set that just includes the test, with a dependency on another CL that
turns on Auto Layout, and ran it on a trybot so that you can see it fail.

> Maybe there's a method you can call directly on
> browser_window->GetNativeWindow() which sets the frame size subject to layout
> constraints?

https://codereview.chromium.org/2742813003/diff/1/chrome/browser/ui/cocoa/bro...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:185:
EXPECT_EQ(272, bounds.height());
On 2017/03/10 07:22:28, tapted wrote:
> 400 / 272 are magic numbers. At the very least they need to be drawn up into a
> constant at the top of the test file and shared with other tests.
> 
> But a lot more appropriate would be to declare something in
> browser_window_controller.h so that -[BrowserWindowController
> initWithBrowser:..] can use them as well.

I was following the surrounding tests here, but that makes sense. Thoughts on
the approach in the latest patch set?

[Sidney San Martín, 2017-03-10 22:28:24]

The CQ bit was checked by sdy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-10 22:29:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-10 23:15:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-10 23:15:40]

Dry run: This issue passed the CQ dry run.

[tapted, 2017-03-13 00:25:36]

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
File chrome/browser/ui/cocoa/browser_window_controller.h (right):

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/browser_window_controller.h:68: inline NSSize
MinWindowSizeForBrowserType(Browser::Type type) {
See later comment for details, but I think we need/want something like

constexpr const gfx::Size kMinCocoaTabbedWindowSize = gfx::Size(400, 272);
constexpr const gfx::Size kMinCocoaPopupWindowSize = gfx::Size(100, 122);

(you'll probably need to define them without an initializer in the .cc so they
have "storage" space)

You can call .ToCGSize() to get an NSSize.

constexpr const NSSize kFoo = {400, 272}; 

might also work. NSMakeSize: probably not (but maybe) - see later comment.

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
File chrome/browser/ui/cocoa/browser_window_controller_unittest.mm (right):

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:33: const
gfx::Size kMinTabbedWindowSize(
I'm pretty sure this will add a static initializer, which will get your patch
reverted once it hits the waterfall. (try declaring `constexpr` to know
beforehand if it's a compile-time constant).

You could do some tricks to make MinWindowSizeForBrowserType `constexpr` instead
of `inline` -- you wouldn't be able to call NSMakeFoo, bug gfx::Size has
constexpr constructors or you could use C-style initializers for `struct
NSSize`.

There's also a downside to the browser.h #include..

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:178:
EXPECT_TRUE(browser_window->GetDownloadShelf());
nit: comment here. Something like

// Requesting the download shelf lazily creates and adds the views to the view
hierarchy, but doesn't make it visible.


But.. It would be nice to have some guarantee that the statement is "verified"
e.g. is there some call we can make to ensure the DownloadShelfView is non-nil,
and has a superview?

[Sidney San Martín, 2017-03-14 23:25:02]

The CQ bit was checked by sdy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-14 23:25:45]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Sidney San Martín, 2017-03-14 23:28:39]

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
File chrome/browser/ui/cocoa/browser_window_controller.h (right):

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/browser_window_controller.h:68: inline NSSize
MinWindowSizeForBrowserType(Browser::Type type) {
On 2017/03/13 00:25:36, tapted wrote:
> See later comment for details, but I think we need/want something like
> 
> constexpr const gfx::Size kMinCocoaTabbedWindowSize = gfx::Size(400, 272);
> constexpr const gfx::Size kMinCocoaPopupWindowSize = gfx::Size(100, 122);
> 
> (you'll probably need to define them without an initializer in the .cc so they
> have "storage" space)
> 
> You can call .ToCGSize() to get an NSSize.
> 
> constexpr const NSSize kFoo = {400, 272}; 
> 
> might also work. NSMakeSize: probably not (but maybe) - see later comment.

Done. I don't think they need storage space
(http://stackoverflow.com/questions/34445336/).

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
File chrome/browser/ui/cocoa/browser_window_controller_unittest.mm (right):

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:33: const
gfx::Size kMinTabbedWindowSize(
On 2017/03/13 00:25:36, tapted wrote:
> I'm pretty sure this will add a static initializer, which will get your patch
> reverted once it hits the waterfall. (try declaring `constexpr` to know
> beforehand if it's a compile-time constant).
> 
> You could do some tricks to make MinWindowSizeForBrowserType `constexpr`
instead
> of `inline` -- you wouldn't be able to call NSMakeFoo, bug gfx::Size has
> constexpr constructors or you could use C-style initializers for `struct
> NSSize`.
> 
> There's also a downside to the browser.h #include..

Hmm, I came very close to making MinWindowSizeForBrowserType() constexpr
originally. I went with your suggestion to avoid the browser.h include.

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:178:
EXPECT_TRUE(browser_window->GetDownloadShelf());
On 2017/03/13 00:25:36, tapted wrote:
> nit: comment here. Something like
> 
> // Requesting the download shelf lazily creates and adds the views to the view
> hierarchy, but doesn't make it visible.

Done.

> But.. It would be nice to have some guarantee that the statement is "verified"
> e.g. is there some call we can make to ensure the DownloadShelfView is
non-nil,
> and has a superview?

It depends on what this test is testing. When I get back to working on the
download shelf, I very much want to not put it in the view hierarchy at all
unless it's visible. At that point, this test will fail. Should the test be
deleted? If the answer is yes, OK. If the answer is no, then IMHO this is a
regression test for a specific crbug and testing for those details just makes it
brittle. Thoughts?

I think those checks would look something like this:

    NSWindow* nativeWindow = browser_window->GetNativeWindow();
    NSView* downloadShelfView = [[[BrowserWindowController
        browserWindowControllerForWindow:nativeWindow] downloadShelf] view];
    EXPECT_TRUE([downloadShelfView window] == nativeWindow);
    EXPECT_FALSE(browser_window->IsDownloadShelfVisible());

[Sidney San Martín, 2017-03-14 23:29:15]

The CQ bit was unchecked by sdy@chromium.org

[Sidney San Martín, 2017-03-14 23:30:54]

The CQ bit was checked by sdy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-14 23:31:45]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-14 23:54:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-14 23:54:58]

Dry run: This issue passed the CQ dry run.

[tapted, 2017-03-15 00:49:51]

lgtm - thanks!

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
File chrome/browser/ui/cocoa/browser_window_controller_unittest.mm (right):

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:178:
EXPECT_TRUE(browser_window->GetDownloadShelf());
On 2017/03/14 23:28:39, sdy wrote:
> On 2017/03/13 00:25:36, tapted wrote:
> > nit: comment here. Something like
> > 
> > // Requesting the download shelf lazily creates and adds the views to the
view
> > hierarchy, but doesn't make it visible.
> 
> Done.
> 
> > But.. It would be nice to have some guarantee that the statement is
"verified"
> > e.g. is there some call we can make to ensure the DownloadShelfView is
> non-nil,
> > and has a superview?
> 
> It depends on what this test is testing. When I get back to working on the
> download shelf, I very much want to not put it in the view hierarchy at all
> unless it's visible. At that point, this test will fail. Should the test be
> deleted? If the answer is yes, OK. If the answer is no, then IMHO this is a
> regression test for a specific crbug and testing for those details just makes
it
> brittle. Thoughts?

My main thought is that testing layout regressions is super-hard and you are
already a champion for going this far :).

I think what you have is good.

> 
> I think those checks would look something like this:
> 
>     NSWindow* nativeWindow = browser_window->GetNativeWindow();
>     NSView* downloadShelfView = [[[BrowserWindowController
>         browserWindowControllerForWindow:nativeWindow] downloadShelf] view];
>     EXPECT_TRUE([downloadShelfView window] == nativeWindow);
>     EXPECT_FALSE(browser_window->IsDownloadShelfVisible());

Of these, I'd perhaps add just EXPECT_NE(nil,  downloadShelfView) or something
to that effect. I don't think that will break once the shelf is not in the view
hierarchy. That's effectively implied by GetDownloadShelf() returning non-null
(just a little more Cocoa-specific), so consider this optional.

[Sidney San Martín, 2017-03-15 03:04:05]

The CQ bit was checked by sdy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-15 03:04:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Sidney San Martín, 2017-03-15 03:05:30]

The CQ bit was unchecked by sdy@chromium.org

[Sidney San Martín, 2017-03-15 03:08:17]

The CQ bit was checked by sdy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-15 03:08:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Sidney San Martín, 2017-03-15 03:13:38]

One last thing…

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
File chrome/browser/ui/cocoa/browser_window_controller_unittest.mm (right):

https://codereview.chromium.org/2742813003/diff/80001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/browser_window_controller_unittest.mm:178:
EXPECT_TRUE(browser_window->GetDownloadShelf());
On 2017/03/15 00:49:51, tapted wrote:
> On 2017/03/14 23:28:39, sdy wrote:
> > On 2017/03/13 00:25:36, tapted wrote:
> > > nit: comment here. Something like
> > > 
> > > // Requesting the download shelf lazily creates and adds the views to the
> view
> > > hierarchy, but doesn't make it visible.
> > 
> > Done.
> > 
> > > But.. It would be nice to have some guarantee that the statement is
> "verified"
> > > e.g. is there some call we can make to ensure the DownloadShelfView is
> > non-nil,
> > > and has a superview?
> > 
> > It depends on what this test is testing. When I get back to working on the
> > download shelf, I very much want to not put it in the view hierarchy at all
> > unless it's visible. At that point, this test will fail. Should the test be
> > deleted? If the answer is yes, OK. If the answer is no, then IMHO this is a
> > regression test for a specific crbug and testing for those details just
makes
> it
> > brittle. Thoughts?
> 
> My main thought is that testing layout regressions is super-hard and you are
> already a champion for going this far :).
> 
> I think what you have is good.

Aw, thanks tapted@.

> > 
> > I think those checks would look something like this:
> > 
> >     NSWindow* nativeWindow = browser_window->GetNativeWindow();
> >     NSView* downloadShelfView = [[[BrowserWindowController
> >         browserWindowControllerForWindow:nativeWindow] downloadShelf] view];
> >     EXPECT_TRUE([downloadShelfView window] == nativeWindow);
> >     EXPECT_FALSE(browser_window->IsDownloadShelfVisible());
> 
> Of these, I'd perhaps add just EXPECT_NE(nil,  downloadShelfView) or something
> to that effect. I don't think that will break once the shelf is not in the
view
> hierarchy. That's effectively implied by GetDownloadShelf() returning non-null
> (just a little more Cocoa-specific), so consider this optional.

I was looking for the best way to add this, and discovered that
BrowserWindowControllerTest already comes with a BrowserWindowController! I just
rewrote the test a little to use it, and to add this check. I confirmed that it
still passes with and without Auto Layout, and fails with Auto Layout and
without the fix. Mind taking another quick look?

[commit-bot: I haz the power, 2017-03-15 03:58:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-15 03:58:39]

Dry run: This issue passed the CQ dry run.

[tapted, 2017-03-15 04:31:46]

neato - lgtm

[Sidney San Martín, 2017-03-15 11:28:19]

The CQ bit was checked by sdy@chromium.org

[commit-bot: I haz the power, 2017-03-15 11:28:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-15 11:32:45]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1489577299209270,
"parent_rev": "f1a7a37514b2eda7e895b0e52d120e937d58b385", "commit_rev":
"d06b1c5641ca1022fd4165ea46d8295fb5a215b4"}

[commit-bot: I haz the power, 2017-03-15 11:33:23]

Description was changed from

==========
[Mac] Lay out the browser window when adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being shown (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, BrowserWindowController doesn't lay out the window after adding
the download shelf. When the download shelf is shown, -layoutSubviews is called
via -resizeView:newHeight:, but in some cases, like a quick extension install,
it's added and left hidden. In that case, the shelf will be positioned like
this (but you can't see it, since it's hidden and has zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
window is wider than the shelf when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf is made
narrower and eventually reaches a minimum size.

If the user makes the window even smaller, one of two things will happen
depending on whether Auto Layout is handling the window:

- No Auto Layout: the layout breaks (but the user never sees it happen, because
  -layoutSubviews fixes it up if the download shelf is shown).

- Auto Layout: The layout engine treats the fixed margin as a constraint and
  prevents the window from becoming any narrower.

The next time -[BrowserWindowController layoutSubviews] runs, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577
==========

to

==========
[Mac] Lay out the browser window when adding the download shelf.

## Summary
This fixes a regression when a browser window uses Auto Layout: if the download
shelf is added to the window without ever being shown (e.g. when installing an
extension), then the window can't be made as narrow as usual.

## Explanation
Before this CL, BrowserWindowController doesn't lay out the window after adding
the download shelf. When the download shelf is shown, -layoutSubviews is called
via -resizeView:newHeight:, but in some cases, like a quick extension install,
it's added and left hidden. In that case, the shelf will be positioned like
this (but you can't see it, since it's hidden and has zero height):

    /---------------------------------------\
    |---------------------------------------|
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |                                       |
    |---------------------------            |
    |                         x|            |
    \---------------------------------------/

The shelf's autoresizing mask has a flexible width but fixed margins. If the
window is wider than the shelf when it's added, then it will have a right
margin. As the user makes the window narrower, the download shelf is made
narrower and eventually reaches a minimum size.

If the user makes the window even smaller, one of two things will happen
depending on whether Auto Layout is handling the window:

- No Auto Layout: the layout breaks (but the user never sees it happen, because
  -layoutSubviews fixes it up if the download shelf is shown).

- Auto Layout: The layout engine treats the fixed margin as a constraint and
  prevents the window from becoming any narrower.

The next time -[BrowserWindowController layoutSubviews] runs, the download
shelf is made the same width as the window, and the problem goes away because
it no longer has a margin.

## Future work
Only add the download shelf to the view hierarchy when it's visible.

BUG=667698, 695577

Review-Url: https://codereview.chromium.org/2742813003
Cr-Commit-Position: refs/heads/master@{#457055}
Committed:
https://chromium.googlesource.com/chromium/src/+/d06b1c5641ca1022fd4165ea46d8...
==========

[commit-bot: I haz the power, 2017-03-15 11:33:25]

Committed patchset #8 (id:160001) as
https://chromium.googlesource.com/chromium/src/+/d06b1c5641ca1022fd4165ea46d8...