Could the Omnibox grow when the entered text doesn’t fit?

Assigning to andresantoso@ because this sounds like a previous  bug 528845  that was also assigned to him.

Note shess@'s interesting comment #6 on that bug explaining the issues with Hindi fonts' bounding boxes.

Also CC shess@ as an FYI.

I see the report is marked restricted - anyone have issues with removing that?  If nobody responds I'll remove it :-).

WRT growing the Omnibox, that's probably a non-starter, because it's likely to have tons of unacceptable edge cases which would only affect a small subset of users, so it probably wouldn't get picked up as a high-priority problem.

If I had all the resources in the world, I'd probably aim to have the omnibox control editor somehow setup to have a gradient bounding box.  Like it would have a strong bound at the focus ring, and a somewhat-transparent pixel within that, then full-transparent within that.

This would also require some work on the selection box, I think.  Not because it needs to select the boundaries of the text, rather I seem to recall once trying to loosen the bounding box in there and finding that the selection box expands to fill.  For text following the ASCII bounding box, this would look rather unbalanced.  I suspect getting the selection box right for all comers might be challenging.

That said, the OSX text-control system is subtle, and quick to anger.  Would MacViews provide an alternative where all platforms are correct (or broken) in similar fashion?

I meant "Tons of unacceptable edge cases for a feature to only benefit a small subset of users".  Basically, I'd hate to generate complicated bugs for everyone for something which will provide poor benefits to a small number of users (I'm not meaning a value judgement, just trying to reflect reality, editing in a field with specific UI goals which works for all scripts is challenging when few of the engineers understand the subtle aspects).

Growing the omnibox is an eventual must-have anyway for a11y, at least on views.  I would suggest planning to do it.

> report is marked restricted
Oh, that was not intentional.

>> report is marked restricted
> Oh, that was not intentional.

It's crbug doing that automatically under certain conditions. Opening up this bug to the public. 

> Growing the omnibox is an eventual must-have anyway for a11y, at least on views.  
> I would suggest planning to do it.

That's welcome news :-). We're talking about potentially a billion of (potential) users (South Asia alone). 

In fairness, this bug is marked as Mac-specific, there's no way way a Mac bug affects a billion people.

Not that we shouldn't fix.

spqchan@ - it looks like this is still happening in Material Design. Can you take a look at this to see what needs to happen to clip less of the text when editing? And also what we need to do to clip a little more of the text when not editing (the text should not overlap the omnibox border).

FYI, still reproduces in Chrome 58.

[mac bug triage] 

This is Mac-only only because on Windows they aggressively squeeze down the glyphs in the font we use so that it fits. Barely.

This is something the Omnibox team should look at.