I don't think there's a UI principle that would help us decide whether the expected result is better than what currently happens.  +rolfe@ for her perspective to see if she has a strong opinion.

Instead, I think we should decide based on whether users actually do this behavior (clear input, then select something).  Perhaps we can do this from current UMA logs.

Regardless, I think showing the current URL is wrong.  Filed bug 685332.  Though I do wonder how it will look to have the highly visited suggestions hanging below a blank omnibox...  Maybe rolfe@ has an opinion on this too.

(+emilyschechter@ as omnibox pm)

Definitely this is a space UX is considering doing more around, but still undecided. Got a couple of relevant slides in this deck (slides 21-37):
https://docs.google.com/presentation/d/1RS6AAT5J_QZaqF7jk-Eqw7NPXxEB1mqM86anKub_hj0/edit#slide=id.g15fd973d4e_2_0

And I know bbergher@ is considering zero-query as a part of assist work. I'd say we're mostly waiting on how Chrome Home project work pans out from cleer@ and pschaffner@ as well.

But emilyschechter@ - open to whatever you might want to do here in the coming months as you solidify an omnibox plan.

Mark suggested I leave this comment here:

It sounds like today, we can give suggestions on an empty omnibox (which is fine), but if you actually hit enter on the empty omnibox in this case, we'll navigate somewhere, at least on Android.  That isn't fine; we always want the omnibox text itself, without reference to the dropdown, to give a clue as to what will happen when you hit enter.  This is particularly important on Android where we don't indicate selection in the dropdown, so it's not obvious that the first match is actually the "selected entry".

There are a couple potential solutions here:
* Don't suggest things on an empty omnibox (probably undesirable)
* Add a placeholder "<enter query>" non-navigable match (we do this on desktop if you e.g. type just "?")
* Add a placeholder match, and also change the dropdown to hide this match, so there is no visible "selected entry"
* Generalize the previous bullet to hide the "what you typed" and placeholder matches in general (we tried this during 1993 and the metrics were bad, but I think we were trying on desktop, and it may make sense on Android given how we style the dropdown)
* Change the code so there actually might _be_ no selected entry (probably harder and riskier than the previous bullets, and would have the same effect)

I believe the third and fifth bullets are effectively equivalent from the user perspective.  Thus, I think Peter offered four meaningfully different user interaction possibilities.

Correct.

Removing myself and adding maxwalker as omnibox design contact. Might also be something bbergher is interested in, for Assist work.

maxwalker@, what do you think the right behavior is?

Awaiting UX or PM feedback.

Ping maxwalker and emilyschechter. For what it's worth, this current behavior doesn't strike me as a problem.

omnibox needs-feedback ping. thanks!

[status update]

maxwalker@ mailed me separately to inquire about metrics about this.  It's clearly on his radar.  Officially assigning to him; when a decision is made, assign it back to the omnibox team.