+pbos@. Related to issue 916209 (comment 10).

It looks like the Mac logic is computing an invalid minimum width for the browser. I thought the Mac logic might be a little sketchy. I might need a Mac laptop to develop on though. Let me see what I can do.

I have found the culprit.

On Windows, when the browser is resizing, we ask the browser window for its minimum size and cap resize at that size. This is a native Windows resize feature (message WM_GETMINMAXINFO).

On Mac, we only ask the browser for its minimum size at startup.

The minimum width of the browser is largely controlled by the toolbar. The minimum width of the toolbar can change over time - if the user elects to show or hide the home button, if the identity chip expands to show a status, if the user navigates to a page that causes the Omnibox to show a security chip. Typically, at startup the toolbar is near its absolute smallest size as none of this additional detail is present.

Previously, when the browser ended up in a state where there was not enough room to display the omnibox, it would scale to below its minimum size, resulting in not being able to display even the entire hostname. This did not produce the kind of visual artifact we're seeing here, however.

Because the Mac only asks for the browser minimum size at startup, it does not include the security chip, cast button, profile chip expansion, etc. So if you navigate to a secure site or start casting and then resize the window to a very small size, previously the Omnibox would become unusably small, but now the toolbar is truncated (because the new FlexLayout logic respects the Omnibox's minimum size).

There are several solutions:
1. Have the browser ask for the window's minimum size on resize, like on Windows. This is the solution that is probably best but that I have least experience with from a platform point of view and would probably have to hand off to ellyjones@'s team.
2. Allow the Omnibox to scale below its minimum size. This would solve a handful of corner cases but could result in equally bad situations where security icons can't be displayed. Also it might require changes to FlexLayout or one of its helper classes to create a new behavior of "report my minimum size as X but allow me to scale down to Y < X".
3. Have Omnibox always report a larger minimum size to accommodate a security chip as well as status icons and enough space for the hostname.
4. Set a floor for minimum browser size irrespective of what BrowserView (and by extension ToolbarView) report.

I want to get feedback as to how we ought to proceed here.
(CC-ing ellyjones@ for a more knowledgeable perspective)

Another option would be to use the ToolbarView's preferred size rather than minimum size in calculating the minimum browser size, but that doesn't feel right either.

Update: let's amend option 3 to actually be "make the minimum size smaller than the current preferred size, but always large enough to show a minimum amount of information.

I think the problem is isolated to BrowserNonClientFrameViewMac, which probably needs to pay attention to BrowserNonClientFrameView::UpdateMinimumSize() - unlike Windows (but apparently like Mus) Mac expects the minimum size to be "pushed" to the window server rather than it being "pulled" when a resize starts. Also, BrowserNonClientFrameViewMac::GetMinimumSize() totally ignores the BrowserView's size constraints, which isn't helping.

I made a CL that implements ::UpdateMinimumSize() in BrowserNonClientFrameViewMac and changes ::GetMinimumSize() to actually listen to the BrowserView: <https://chromium-review.googlesource.com/c/chromium/src/+/1417731>. I ran the repro steps from this bug against that CL and it appears to fix it.

Thank you so much for doing this. I've been out sick but I'll take a look at the CL.

I'm handing off the bug; feel free to hand it back if you think there's other work that needs done on it.

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

commit a5e24036a831654fd74451a09a86e6ea33619dc1
Author: Elly Fong-Jones <ellyjones@chromium.org>
Date: Tue Jan 22 15:25:05 2019

macviews: honor BrowserView minimum size

BrowserNonClientFrameViewMac ignores the size constraints of the BrowserView
and uses a hardcoded window size. This breaks when the BrowserView's layout
requires more space than the hardcoded window minimum size allows. This change
causes BrowserNonClientFrameViewMac to compute the its minimum size correctly
(including the Mac-specific width-to-height ratio for minimum sizes) and keeps
it synced to the WindowServer so that window resizes actually honor it.

Bug: 921964
Change-Id: I696471cbfbc6fdb0fa9f269a17a10f458536ca89
Reviewed-on: https://chromium-review.googlesource.com/c/1417731
Reviewed-by: Dana Fried <dfried@chromium.org>
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624785}
[modify] https://crrev.com/a5e24036a831654fd74451a09a86e6ea33619dc1/chrome/browser/ui/views/frame/browser_non_client_frame_view.h
[modify] https://crrev.com/a5e24036a831654fd74451a09a86e6ea33619dc1/chrome/browser/ui/views/frame/browser_non_client_frame_view_mac.h
[modify] https://crrev.com/a5e24036a831654fd74451a09a86e6ea33619dc1/chrome/browser/ui/views/frame/browser_non_client_frame_view_mac.mm

Hi ellyjones@: I tested Chromium Snapshot Version #624808 which includes your CL and unfortunately this isn't completely fixed :(

It still happens to first shrinked window when you Start Chromium. 

I attached a screencast. You also see, that when you resize the window, the top part moves beneath the Menubar.

Maybe you can take a look again, when your fix is in Canary.

Thanks in advance :)

Deleted: screencast.mov 3.8 MB

	screencast.mov 3.8 MB View Download