New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 11 users

Issue metadata

Status: WontFix
Closed: Feb 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

issue 58915

Sign in to add a comment

Issue 331373: Origin chip eliding per spec

Reported by, Jan 2 2014 Project Member

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".

Comment 1 by, Jan 2 2014

Labels: Cr-Security Cr-UI-Browser-Omnibox

Comment 2 by, Jan 3 2014

Labels: Cr-UI-Browser-Omnitheatre

Comment 3 by, Jan 6 2014

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.

Comment 4 by, Jan 14 2014

Labels: -Pri-2 Pri-1
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.

Comment 5 by, Jan 14 2014

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.

Comment 6 by, Jan 14 2014

For reference and testing, and example of a +1 == 63 characters is

Comment 7 by, Jan 14 2014

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.

Comment 8 by, Jan 15 2014

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.

Comment 9 by, Jan 15 2014

Labels: Cr-Security-UX

Comment 11 by, Mar 5 2014

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.

Comment 12 by, Mar 12 2014

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.


Comment 13 by, May 21 2014


Comment 14 by, Jun 9 2014

Labels: -Pri-1 -Cr-UI -Cr-UI-Browser-Omnitheatre Pri-3
Because the origin chip work is backburnered, dropping this to P3.

Comment 15 by, Jun 25 2014

Blocking: chromium:58915

Comment 16 by, Feb 10 2015

Status: WontFix
The origin chip is dead.

Comment 17 by, Dec 9 2016

Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label

Sign in to add a comment