Issue 331373:
Origin chip eliding per spec

Issue description

The origin chip eliding spec says:
(1) Show the entire TLD+1 portion as long as the "+1" is <= 63 characters.
(2) For longer +1s, or hostnames with more components, leading-elide as necessary so the width of the origin chip is not more than 50% of the available space, to the degree that this is possible without violating (1).
Right now, the behavior seems to be "trailing-elide to 50% of the available space".

Discussed this a bit this morning. dcblack, do you want to weigh in?
It's true that the behavior implemented changed from the doc as a result of discussions. We'll have to pick an eliding behavior regardless, since narrow windows will force eliding in some cases. I think the issue is whether there's a max width or not. We could also change the eliding behavior to something more custom, if desired.

We don't, actually, necessarily "have to pick an eliding behavior regardless". We can clamp the window min width so that there is no eliding necessary beyond that described in comment 0.
The stuff in comment 0 was done pretty explicitly in consultation with security. Deviating shouldn't have happened without them and me both knowing. Please share any such discussions that happened, because for the moment I still consider the current behavior critically flawed.

Would the window auto-expand in width if it's too narrow when the user
visits a page with a long domain name?
Check your email for the 11/6 minutes which Ruby sent out -- that's where I
first see mention of this, but I recall it being discussed more than once.
It wasn't a cabal action :-) I don't know if you were there though -- it
was pretty early in the process. I don't know what the status of security
review on that was. Ruby?
In any case, I'm not opposed to changing the policy, but I do think we'll
end up with some eliding behavior in some situations.

At least on Windows, the window doesn't immediately auto-expand today, but it will snap to the larger size as soon as a user touches the resize border. Users are likely to do this since the toolbar contents will clearly be clipped by the trailing window edge.
Note that based on the way comment 0 item (2) is written, when we're in super-narrow situations, we would normally let the omnibox go all the way to its min width, which should be (but currently isn't -- I need to fix this) 10 characters plus any internal icons. The "50% rule" only applies when the window is wide enough to accommodate it.
I don't believe I have the 11/6 meeting minutes. I think maybe I wasn't on the omnitheatre list at that point.

For reference, the 11/6 notes say "Origin chip’s max width - should be up to 50% of Omnibox’s original width" and we opened up discussions with the security team afterward about the desired eliding behavior. Pulling from that doc:
"The origin chip will have 50% max-width (leaving space for the Omnibox), so in certain cases, especially in smaller windows, the hostname will be elided. We’d like some guidance from the Chrome security team on which text eliding option is best... Decision: Elide at front, but ensure the TLD + 1 is not elided unless the '+1' portion is > 63 characters."
To summarize, I believe what we need to do allow the origin chip to be > 50% width in order to show the TLD+1 fully, when the TLD+1 is <= 63 characters. If the window width is too small for this, then shrink the Omnibox to is min-size and leading-elide the origin chip.

With the chip on the left (chrome://flags/#origin-chip-in-omnibox), I now see the chip disappearing when it can no longer fit in the Omnibox. Instead, we should keep the chip around and elide at the front of the text if necessary.
Assigning to jdonnelly because he's been working with this lately.

Per conversation with jdonnelly@, he is going to move the eliding logic into a platform-independent location. Subsequently either macourteau@ or groby@ will fix the chip disappearing completely on Mac when it can no longer fit within the width of the Omnibox.
Thanks!