Using the per-revision bisect providing the bisect results,
Good build: 56.0.2886.0 (Revision: 424099).
Bad build: 56.0.2888.0 (Revision: 424625).

You are probably looking for a change made after 424608 (known good), but no later than 424609 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/751e1f52e94d3d611e27571de632b6a8faa7fc34..42c6683729d8e049fdcc89e552bdcff5fb337227

@eugenebut -- Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Thank You.

Trent, did we disable my "fix"?

Yup, in r433658 but it needs merging (r433658 is in 2927 which hasn't hit Canary yet, so not eligible).

And if this was reported in 2924 then it probably wasn't fixed by r432024, which is in 2920. So I'll set this as a blocker for re-enabling.

I'll do the merge in  Issue 666415  which is releaseblock-beta

Moving this to available since it's not in my queue.

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

Adding TE-Verified labels.
Thanks!

Deleted: 667698.mp4 1.4 MB

	667698.mp4 1.4 MB View Download

Shouldn't this be marked as fixed?

The current fix for this issue is a revert (r433658) of something we want to reland ( Issue 605219 ). So this issue still needs a proper fix.

As per Comment#8, removing TE Verified labels.

tapted@ Please let us know once proper fix get landed.

Thank you.

@tapted -- Any latest updates regarding the Fix, please let us know so that the issue would be checked on latest builds and changed to Fixed state.
Thank You.

I'm not currently working on a fix. A fix isn't what's needed: we just need to ensure this bug doesn't happen again when resolving the blocked,  issue 605219 .

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

commit d06b1c5641ca1022fd4165ea46d8295fb5a215b4
Author: sdy <sdy@chromium.org>
Date: Wed Mar 15 11:32:41 2017

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

[modify] https://crrev.com/d06b1c5641ca1022fd4165ea46d8295fb5a215b4/chrome/browser/ui/cocoa/browser_window_controller.h
[modify] https://crrev.com/d06b1c5641ca1022fd4165ea46d8295fb5a215b4/chrome/browser/ui/cocoa/browser_window_controller.mm
[modify] https://crrev.com/d06b1c5641ca1022fd4165ea46d8295fb5a215b4/chrome/browser/ui/cocoa/browser_window_controller_unittest.mm