Here are three screenshots, one of the current behavior, one without the bolding, and one without the bolding and the extra search text.

I don't have a strong preference.  Does anyone else?

Adding rolfe@ to see if she does.

Android is going the no_search_prompt way.  I'm wondering if it's appropriate to do on desktop as well.

Deleted: current.png 48.3 KB

	current.png 48.3 KB View Download

Deleted: no_bold.png 47.1 KB

	no_bold.png 47.1 KB View Download

Deleted: no_search_prompt.png 43.3 KB

	no_search_prompt.png 43.3 KB View Download

Oh, I didn't realize you were doing this for inexact keyword matches.  I was thinking you were only touching the behavior when we were in keyword mode.

I definitely don't like the middle option.  The current behavior and the no prompt behavior are both better.  I'd probably be OK with either of those.

>>>
Oh, I didn't realize you were doing this for inexact keyword matches.  I was thinking you were only touching the behavior when we were in keyword mode.
>>>
Within keyword mode behavior (at least for custom search engines) is already correct, as this comes from SearchProvider.  Only KeywordProvider, which serves inexact keyword suggestions and I guess some extension things, is affected.

I lean towards No. 3 for simplicity/less to read. Added bonus that it's also the Android model!

rolfe@:

I began the code implement the solution we agreed on (number 3).  Recall this change currently revises the text:
* Search amazon.com for fjdklsj - amazon.com Search
to
* fjdklsj - amazon.com Search

Another question came up in the code review.  When the user hasn't typed anything after the keyword, we currently display.
* Search amazon.com for <enter query> - amazon.com Search
To make this parallel with the new code, I'd like to make this say simply:
* <enter query> - amazon.com Search

Is that okay?

Could you tell me how to reproduce that? Or send a screengrab? When I've typed the keyword and don't type anything afterwards I don't get the "Search" prompt, but the attached. Might be misunderstanding the flow though.

Deleted: BlankQuery.png 36.1 KB

	BlankQuery.png 36.1 KB View Download

rolfe@: it doesn't often trigger.  (Read: I still don't fully understand the rules for getting it to trigger versus, say, collapses with a URL suggestion as your example.)  Here's an example screenshot from one way I got it to trigger.

Deleted: example.tiff 79.2 KB

example.tiff 79.2 KB Download

Ah okay.

1. What happens if you don't enter a query but do press enter when the <enter query> prompt is on screen? (for the one shown in No. 6 we don't allow a search.)
2. Could we always use the one shown in No. 6 instead of having two options?

> 1. What happens if you don't enter a query but do press enter
> when the <enter query> prompt is on screen?
Nothing happens.  The omnibox is cleared/canceled and the user does not navigate anywhere.  The underlying page does not change.

> 2. Could we always use the one shown in No. 6 instead of having two options?
No.  The picture you show in #6 is because the search engine keyword name is also a URL.  If the search engine keyword is something else, like "blahblah", or even "@", we can't present a display like the image in #6 because it's not a known URL.  (Well, technically "blahblah" could be an intranet URL, the omnibox tries not to make single-word inputs go to intranet URLs unless it has reason to believe the intranet URL exists.)  So we can't put a display of a URL with title of these type of search engines.

In case you want to reproduce the "<enter query>" prompt, I think the following should work: take one of your search engines and rename it to a word you've never typed before, then go to the omnibox and type that word followed by a space.

Hmm OK... What's the likelihood this thing could fail since we can't confirm it's a URL? Could we do something like the attached? (I'm mostly just not a fan of "<enter query>" showing up in front-facing text.)

In this proposal if you click on it we try to determine the URL (as in the Maps case) or we drop the search like we would if it's blank.

Deleted: Comparison.png 78.6 KB

	Comparison.png 78.6 KB View Download

I want to keep <enter query> here.  Given how the UI animates in, I don't think the proposals in comment 10 are as good.  This is more readable and understandable.

Also comment 9 is incorrect at least for Windows.  If you hit enter while the prompt is up, we don't clear/cancel the omnibox.  We ignore the keystroke.

+ainslie who is good with strings

I can't find an example of us saying "<enter query>" anywhere else in our UI. It just feels a bit technical (which might be OK since they are likely power users if they are renaming custom search engines.) But if we could polish it while we're here that would be awesome.

In the search engine keyword HC article we say "type your search term"
https://support.google.com/chrome/answer/95655?hl=en&ref_topic=14676

So maybe:
Enter search term - argh Search

Hmm. :/ 

"search term" feel friendlier to me than "query". 
I wonder if "type" could work as a verb instead of "enter"? 

rolfe and ainslie, what's the final word on this?

"Type search term - argh Search" works for me.

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

commit 2b86465902c5d8e89d75cd6b8c6c2ba21f7b9b2d
Author: mpearson <mpearson@chromium.org>
Date: Tue Apr 05 23:32:18 2016

Omnibox - Keyword Provider Shouldn't Bold What-You-Typed Queries

Currently we don't bold what-you-typed queries from the default search
provider, not do we bold what-you-typed queries when the keyword is
typed exactly.  We do bold what-you-typed queries for inexact keywords.

The change makes it so we don't.

It also retires a string that is no longer needed after this change.

BUG= 593245 

Review URL: https://codereview.chromium.org/1784233003

Cr-Commit-Position: refs/heads/master@{#385323}

[modify] https://crrev.com/2b86465902c5d8e89d75cd6b8c6c2ba21f7b9b2d/components/omnibox/browser/keyword_provider.cc
[modify] https://crrev.com/2b86465902c5d8e89d75cd6b8c6c2ba21f7b9b2d/components/omnibox/browser/keyword_provider_unittest.cc
[modify] https://crrev.com/2b86465902c5d8e89d75cd6b8c6c2ba21f7b9b2d/components/omnibox_strings.grdp