You can always edit the keyword to your preferable length in settings.

Clear history means CLEAR history, and should not even leave out a trace hinting you have done searches on certain search engines, I believe.
But I am having a flashback that it was intentionally changed to not to clear the search engine settings...?
Either way, again, you can always edit the keywords to your convenience. If you don't feel like to type it long, why leave it long?

I'm setting search keyword equal to domain of the site. You offer me to change my experience.

You may consider fact of having keyword for domain as bookmark for it, since chrome offers autocompletion for bookmarked urls.

pkasting@: if this behavior intentional?  I vaguely thought we were suggesting keywords in the dropdown if the user typed the beginning of one (regardless of whether the user has visited the site before).  Yet, clearly by this bug report and my experimentation, we're not.

We're not, and I don't know whether we should.

Doing so could help bootstrap keyword usage, especially after clearing history or for sites you've only visited (not typed) before.

But to have much effect, we'd have to make these be the default, inline-autocompleted result in at least the "I cleared history" case.  That worries me.  I don't know that "visit a site, get its search keyword added, now it's inline-autocompleting" is a good effect.  And I'm not sure the case of "I just cleared my history and have never visited anything" is one that matters enough to try and optimize for.

Maybe there's a win in here somehow, but it seems like this is a low-benefit, higher-risk type change.

>>>
But to have much effect, we'd have to make these be the default, inline-autocompleted result in at least the "I cleared history" case.
>>>
Why?  It think it would suffice to the few users in this situation to see the keyword offered below so they can arrow down to it and keep typing / hit tab.  The users who use custom keywords are sophisticated; they just want to save on the typing.

We do suggested partially-typed keywords, but only if there is a query after the text.  For example, if you have amazon.com as a keyword and no history, if you type "ama foo" you get a suggestion to search amazon.com for "foo" in the dropdown.  But you don't get a suggestion in the dropdown for simply typing "ama" that lets you invoke the amazon.com search engine.  I think we should.

Half-tangential note:

We don't offer non-navigable matches, and I don't think we should.  Entries in the dropdown are suggestions of things you can actually do, intentionally not accelerators that aim to reduce but not eliminate future typing and can't be used on their own.  (This is a similar problem to why we don't suggest URLs that we synthesize from the longest common prefix of other matches, except in the case of bare hostnames, which we know are usually navigable.)

This is why we don't suggest dropdown entries for search engines requiring replacement when you haven't typed a replacement string.

OK, note over.  With that said:

It's reasonable to offer an entry for a search engine that, when chosen without entering an additional string, goes to the search engine's site to let you search further.  The problem is that we don't necessarily know where that URL is.  If I enter a custom search engine for mysite.com/foo/bar?baz=%s&id=7, and make the keyword "hello", then what should we display in the dropdown for "he"?  An entry for just "hello" that can't be navigated directly?  That violates the principle above.  But what else can we do?  Just go to mysite.com?  How do we know that's related?

> The problem is that we don't necessarily know where that URL is. ... what should we display in the dropdown for "he"?

Ideally, for auto-generated search engines, we should remember the original URL that caused them to get created and use that.  I don't know how to deal with manually-edited search engines.

And this auto-generated suggestion doesn't help this particular use case because if the user clears browsing history, Chrome should probably clear the URL that's recorded as being associated with auto-generated custom search engines too.

Another possible solution (for auto-generated and manual custom search engines) is to navigate to the search engine with an empty string in the search field.  I think virtually all search engines will return something reasonable for that, and it's an understandable behavior from the user's end.

That raises consistency problems.  Let's say I have a keyword of "foo".

* If typing 'f' produces a "foo" entry in my dropdown that does an empty-string search on the "foo" engine, shouldn't typing "foo" do the same?  But now how do I search for "foo"?  We almost certainly don't want "foo" to default to this -- we've had lots of bugs in the past where people intended DSP searches for e.g. "foo bar" in this kind of a case and got a custom search instead, this seems like it would make those much worse.  But if we don't do this, then we get one of those "when you type the whole word, the behavior silently changes" cases.

* If we made "foo" alone do a search, wouldn't this suggest that "amazon.com" alone should do an "empty string" search on my custom amazon.com search engine entry?  If no, how would we distinguish the two cases?

> If typing 'f' produces a "foo" entry in my dropdown that does an empty-string search on the "foo" engine, shouldn't typing "foo" do the same?
No necessarily.  If the entry in the dropdown says "Search foo:", then I don't think users will think typing "foo" and pressing enter will necessarily do a search on foo (because in the latter case, the omnibox will not say "Search foo:").  It will have a tab-to-search hint at the right.

> But if we don't do this, then we get one of those "when you type the whole word, the behavior silently changes" cases.
This is only a problem for inline autocompletions.  I've said before that I don't think we should be inline autocompleting these search engine suggestions.  In this case, when you type the whole word, you'll still have enter be a search for what you typed.

> If we made "foo" alone do a search, wouldn't this suggest that "amazon.com" alone should do an "empty string" search on my custom amazon.com search engine entry?  If no, how would we distinguish the two cases?
Again, I think UI is the answer.  I can see the concern if the omnibox dropdown that suggests the search engine foo simply says "foo" (or simply suggests "amazon.com"), but if it clearly looks different (e.g., with a "Search engine:" chip), I don't think users will get confused.  If a user types amazon.com in the omnibox and it doesn't display a search chip--the user hasn't hit tab or space yet--then I don't think the user will think pressing enter would go to the same place as the omnibox dropdown suggestion "Search amazon:".

You're saying you want to mark these as "can't be default" so they can only ever appear in the dropdown below the current entry, regardless of what the user types?

This is why I said initially that this seems low-benefit.  We already know users don't look much at the dropdown entries, and if you couple "plus, this entry doesn't even do anything useful, you still have to type more to actually search; also, remember, this is only for the case when the user just cleared all their history, but not their search engines", the added utility seems very low.

Okay, I think we agree: very low benefit, requires proper UI, yet a reasonable request.  Not something I'll work on, but it's available to a motivated contributor.

The NextAction date has arrived: 2018-01-09

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The NextAction date has arrived: 2019-01-08