Much of this already happens today, it's just that the minimum width for the omnibox is really, really tiny.  But you can see it if you pull out all your extensions and then shrink the window down - not all extensions will fit, and will be auto-overflowed.  So the easiest fix for this is to just adjust that existing minimum width.

> A simple proposal is to set a minimum width for the omnibox and then push all extension icons into overflow that don't fit, using some simple way to prioritize them (like show the active ones, hide the inactive ones).

The current behavior is to preserve the ordering, and just overflow them.  This is for two reasons:
- Determining what an "active" extension is is actually very difficult - one that modifies the content of the tab?  Ones that modify the browser?  Ones that are passively informative?  etc.  Additionally, if it is conditional based on the tab, then switching tabs back and forth results in a bunch of icons moving around - which is quite confusing to the user (we've tried it in the past - it's very hard to understand what's going on when your toolbar state radically changes between example.com and chromium.org).
- Having different ordering between windows is also rather weird.  Unless we wanted to apply the same ordering across all instances (effectively removing the ability for users to reorganize extensions), then window A may have a very different extension order than window B, if they are different widths.

Because of the complications here, I'd advise against trying to be too smart with which extensions we show, at least at first.

> IMO it would look/feel better if the rule was something like "the omnibox should always be 2/3 the width of the toolbar"

I agree that this would be better than just blanket-saying "300px" (which I believe is more-or-less what we have today).  I think 2/3 is a little too high to be the minimum, but saying something like "1/3 or 300px, whichever is greater" seems quite reasonable.  But, just my $0.02. :)

Because of the complications here, I'd advise against trying to be too smart with which extensions we show, at least at first.

+1. I think that simply changing the min. width while preserving the ordering would be a reasonable v1.

 Issue 58915  has been merged into this issue.

In summary, then, I think everyone agrees there should be some greater minimum width than there is now. And that the rest of the toolbar will handle this gracefully.

Some info on the current minimum: the Views omnibox reserves for the text (i.e. not including the security chip or page actions) the expected length of 10 characters (as estimated by the font system):
https://cs.chromium.org/chromium/src/chrome/browser/ui/views/omnibox/omnibox_view_views.cc?l=330&rcl=14bf1ca3049897e85e1dd527ef0ec51f65ea5e7c

So the simplest thing to do would be to increase that value to some number > 10. I'd argue that "characters" is a better measure than "pixels" for a raw minimum since it's sensitive to the font size* and satisfies our desire to reserve enough space to clearly convey textual security information (i.e. the domain+TLD).

I think we should just double this to 20, though it should be tested carefully to make sure that it's not *too* large (it's possible that with a large font, and EV cert, several page actions and the new, more spacious GM2 buttons that a minimum of 20 would cause the minimum window size to be uncomfortably large).

* The omnibox font size is currently difficult to change but we mean to fix this: https://crbug.com/740841.

Does Chrome for Android have a different min width? To stay consistent.

It is much better nowadays because the icons overflow nicer, but still can
lead to a bad UX.

The Android UI is pretty different as it has no page action icons or plugin icons. The toolbar reserves (I believe) a fixed amount of space for a few buttons and then the omnibox always gets the rest.

Just got another informal report that this is a problem with lots of extensions on a touchscreen device. Bumping the priority and milestone as I think the fix I proposed in #4 should be easy and effective assuming it doesn't introduce some unexpected issue.

manukh: please coordinate with tommycli re: the priority of this relative to the other work you're doing. The task here is to simply increase the minimum width reserved for the omnibox (as described in #4) and then to try it out with a large number (at least 8-10) of extensions installed. Questions to confirm:

- Does the change I described produce the desired outcome? (The omnibox should not get so small as to obscure most of the text, while the extensions should be automatically moved into the Chrome menu to accommodate it.)
- The larger minimum width for the omnibox will result in a larger minimum width  for the entire window. Does this seem too large?
- Does 20 as a minimum feel good or would another value work better?
- Do any other unexepected issues arise once the minimum width is larger?

Also, please be sure to try out the change both with and without chrome://flags/#upcoming-ui-features enabled.

I'm wondering if 20 characters is enough. Here is what I see when I adjust my window size so that only 20 characters are displayed (assuming we count the "..." shown when the URL gets cut off): https://screenshot.googleplex.com/tJvDUnFUq6k.png

Still seems somewhat squished and not really readable.

Do we have metrics on window width?  Realistically, I don't think it's practical to say that Chrome will look great with both a minimum-width window and a ton of extensions, but I think we might be able to satisfy the 99%ile case for each.

IIRC, +felt@ had some metrics..

I wasn't the one with data for this specific issue, I was just cranky because the URL bar was getting really small on my chromebook. ;) But we have screen resolution data in UMA if you want to look it up: hardware.primary_screen_width. You can use my plx script: https://plx.corp.google.com/script/#a=qo%7Ci=google%253A%253Ascript_a9._1821c0_bd94_450c_93f4_77507ba16beb.

Note that the data felt@ links to is about the dimensions of the screen, not the size of the user's browser window.  I'm not aware of any information we have about actual window sizes, sorry.  (I looked--I couldn't find anything, surprisingly!)

Would love to see if we could track actual window size metrics. This would be super useful for UX to have a target size to design around. 

Random question, are we most concerned about the min-width for the resolved OB state or the raised/suggestion states? Or both? I'd like to mock some potential paths forward, even if this is post M-69. Any objections? 

I'm most concerned with the resolved OB state since it's a security surface, but we should also consider the editing states.

Sounds like we are in agreement that our first step is increasing the min-width as described in characters in the omnibox.

Joel, can you get us a reasonable number? If it were me (not a UXer), I'd say at least 20. I'd be fine with more given how the rest of the toolbar logic works.

Ill put together a proposal. This SGTM. 

Additionally, I also want to consider how these minimums coincides/align with the raised suggestion states soon as well. This state feel more broke to me in the UI, even if the N# of characters are visible. 

https://screenshot.googleplex.com/zgsKjjLwbvL.png

re bklmn@ comment #17:
I filed bug 857191 to track the request to record actual window dimensions.  You'll probably need to get a desktop lead to ask someone to work on it.

Labeling this Proj-MdRefresh because the issue is exacerbated in the new UI and I'd like to track it as part of that effort.

20 characters seems fine to me, with and without the upcoming ui features flag. Will go ahead and make a cl unless someone prefers larger/smaller than 20.

Deleted: refresh.png 74.0 KB

	refresh.png 74.0 KB View Download

Deleted: pre-refresh.png 61.0 KB

	pre-refresh.png 61.0 KB View Download

Deleted: 20 extensions.png 199 KB

	20 extensions.png 199 KB View Download

Those screenshots are fantastic, thanks. Agreed that 20 seems like a good, incremental improvement for now. I just lgtm'd your CL.

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

commit 01a5a40f27ac01ee9ebff5cfc78e1cb66520f3d8
Author: manuk <manukh@chromium.org>
Date: Fri Jul 27 14:04:36 2018

Omnibox: increase omnibox minimum width

Omnibox width was 10 characters (plus some extra for page actions and location bar bubbles), and is now 20 characters.

Bug:  849784 
Change-Id: Iaacab5244b5f1c21156151f49e0405e844f09451
Reviewed-on: https://chromium-review.googlesource.com/1135147
Reviewed-by: Jonathon Kereliuk <kereliuk@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Reviewed-by: Tommy Li <tommycli@chromium.org>
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Commit-Queue: manuk hovanesian <manukh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578623}
[modify] https://crrev.com/01a5a40f27ac01ee9ebff5cfc78e1cb66520f3d8/chrome/browser/devtools/devtools_sanity_interactive_browsertest.cc
[modify] https://crrev.com/01a5a40f27ac01ee9ebff5cfc78e1cb66520f3d8/chrome/browser/prefs/pref_service_browsertest.cc
[modify] https://crrev.com/01a5a40f27ac01ee9ebff5cfc78e1cb66520f3d8/chrome/browser/ui/views/omnibox/omnibox_view_views.cc
[modify] https://crrev.com/01a5a40f27ac01ee9ebff5cfc78e1cb66520f3d8/chrome/test/chromedriver/test/run_py_tests.py
[modify] https://crrev.com/01a5a40f27ac01ee9ebff5cfc78e1cb66520f3d8/chrome/test/data/extensions/api_test/window_update/sizing/test.js

Hello manukh@: I tested the latest Chromium Snapshot #578633 and seems that there is a small edge case (may be only on Mac?). If you shrink the window to its smallest horizontal size, the 3-Dot-Menu button is now moving to the right border.

Here is a screencast.

Deleted: mac_small_window_size.mov 4.8 MB

	mac_small_window_size.mov 4.8 MB View Download

re c#30, dupe: crbug/842239

mehmet@, i don't see the issue on linux (attached screenshot). Also, i changed minimum width only for windows & linux; you're window looks like it's thinner than the new min width. On my machine, at min width, the omnibox fits `[chrome icon] chromium | chrome://version12 [star]`

Deleted: display.png 28.2 KB

	display.png 28.2 KB View Download

manukh@: Yes, as markchang@ mentioned in #31, this issue was already present in MacViews ( issue 842239 ). After your change, the moving starts now earlier on Mac when the windows shrinks horizontally. It seems that the min-width on Mac is smaller than on Linux or Windows to match other Mac Applications ( issue 827199 ).

Verified in today's Windows Canary (70.0.3507.0).

Your change meets the bar and is auto-approved for M69. Please go ahead and merge the CL to branch 3497 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Rejecting merge to M69 per chat with jdonnelly@. Pls re request merge to M69 when ready and safe to merge. Thank you.

We held off on merging this change yesterday due to  https://crbug.com/868836 . However, that issue was deemed low priority and only an exacerbation of an existing issue.

Re-requesting merge.

Your change meets the bar and is auto-approved for M69. Please go ahead and merge the CL to branch 3497 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Pls merge to M69 branch 3497 ASAP. Thank you.

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

commit ca2d3d7bfe31255616d929f4dca937c6cea81bcc
Author: manuk <manukh@chromium.org>
Date: Thu Aug 02 16:44:27 2018

Omnibox: increase omnibox minimum width

Omnibox width was 10 characters (plus some extra for page actions and location bar bubbles), and is now 20 characters.

Bug:  849784 
Change-Id: Iaacab5244b5f1c21156151f49e0405e844f09451
Reviewed-on: https://chromium-review.googlesource.com/1135147
Reviewed-by: Jonathon Kereliuk <kereliuk@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Reviewed-by: Tommy Li <tommycli@chromium.org>
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Commit-Queue: manuk hovanesian <manukh@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#578623}(cherry picked from commit 01a5a40f27ac01ee9ebff5cfc78e1cb66520f3d8)
Reviewed-on: https://chromium-review.googlesource.com/1160941
Cr-Commit-Position: refs/branch-heads/3497@{#339}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/ca2d3d7bfe31255616d929f4dca937c6cea81bcc/chrome/browser/devtools/devtools_sanity_interactive_browsertest.cc
[modify] https://crrev.com/ca2d3d7bfe31255616d929f4dca937c6cea81bcc/chrome/browser/prefs/pref_service_browsertest.cc
[modify] https://crrev.com/ca2d3d7bfe31255616d929f4dca937c6cea81bcc/chrome/browser/ui/views/omnibox/omnibox_view_views.cc
[modify] https://crrev.com/ca2d3d7bfe31255616d929f4dca937c6cea81bcc/chrome/test/chromedriver/test/run_py_tests.py
[modify] https://crrev.com/ca2d3d7bfe31255616d929f4dca937c6cea81bcc/chrome/test/data/extensions/api_test/window_update/sizing/test.js

+abdulsyed@ fyi, M69 merges taken for Proj-MdRefresh .