Just curious: where (what URL or query) were you intending to go to when you started typing "shop.critical"?

I just was attempting to see if shop.criticalrole.com was a real site. (It's not, so much.)

[forgive the rambling reply; I'm thinking through things]

> if "shop.critical role" is not marked "allowed to be default", it would autocomplete.
This is a foible of chrome://omnibox.  chrome://omnibox doesn't know what was previously cached.

The omnibox tries to only allow inline autocompletions to be completed synchronously, not asynchronously.  Thus, chrome://omnibox thinks anything that comes back from the server cannot be marked as a legal default match.

However, the real omnibox probably has the suggestion "shop.critical role" cached from the input ""shop.critica", and thus could synchronously make it the default match when the user typed the "l".

> In any case, regardless of what Google is suggesting, the Omnibox should
> be more sensitive to what appears to be the beginning of a hostname.
I agree that inline autocompletion here looks bad.

The omnibox does recognize that the input may be a query or a URL, classifying it as UNKNOWN.  Likewise "mail" is also classifies as UNKNOWN.  So that's working right.

Meanwhile, the server is actually assigning the query suggestions the lowest score possible, meaning it's recognizing those as "likely URL seeking, not query seeking."  That's good too.

At issue is the fact that there's an inline autocompletion here.  So, even if the server is assigning as low scores as it can, it puts one query with an inline autocompletion higher than another.

This does seem a bit aggressive.  But the server knows a lot, so maybe that longer query (the completion) is actually better than the query for "shop.critical".

I think this goes in the collection of queries for which the server may be too eager.  We collected a bunch and fixed them in  bug 157029 .

For now, I don't think this example is persuasive enough to entice us to rejigger server scoring.  ("shop.critical" doesn't sound like any more likely a search query to me than "shop.critical role".)  So WontFix.  But if you come up with other examples, perhaps more convincing (i.e., the spot at which you stop typing looks definitively more like a search query than the inline completion, please file a new bug.

P.S.  I checked: ".critical" is not a valid top-level domain, so I don't think this counts as an "obvious" hostname.

So a result that is not 'can be default' can in fact be default? This seems surprising. To be specific, the Omnibox is putting the 852 score can't be default result above the 851 score can be default, but lists it second in chrome://omnibox.

> P.S.  I checked: ".critical" is not a valid top-level domain, so I don't think this counts as an "obvious" hostname.

By "obvious", I meant that the '.' dot is a very strong signal that it's the beginning of a hostname. Specifically, a suggestion that the next character is probably a space should maybe be last in the list. I wonder if Chrome could show more insight here.

fwiw, Firefox assumes that it's the beginning of a host, even with suggestions turned on.

>>>
So a result that is not 'can be default' can in fact be default?
>>>
No, the issue is that the chrome://omnibox output does not actually reflect what the omnibox is doing.  The omnibox, based on caching from prior keystrokes, has figured out that it can be default and puts it first.  chrome://omnibox cannot make that inference and so leaves it second.

>>>
fwiw, Firefox assumes that it's the beginning of a host,
even with suggestions turned on.
>>>
Can you post a screenshot?  And what does pressing enter do in firefox?

Pressing enter attempts to navigate to www.shop.critic

Deleted: firefox-shopping.png 13.2 KB

	firefox-shopping.png 13.2 KB View Download

Thanks krb@ for the screenshot.  I think that firefox behavior bad too.  (Trying to navigate to a page that we can tell a priori is invalid.)

I don't think we can predict every enterprise naming scheme. Their choice doesn't appear harmful.

The benefit to displaying this as a navigation before the user is done typing is to confirm to the user that we agree that it's a host name, or to visually inform them that they inserted hard to see punctuation.

So I wouldn't use words like 'bad', but instead just different, and, frankly, what I was expecting when I entered the text.

Good point that enterprises may have subdomains that we're not aware of.  I think the best solution for this would be not to blanket assume all things like x.y are navigable is to fix bug 104638, which would make one successful navigation to a subdomain teach Chrome that the subdomain exists in the future.  That anything like foo.subdomain will be URL navigations by default.