There's basically no signal in this case -- no local history and only one character in the omnibox.  I'm reluctant to care too much about it.  I would probably WontFix this.

If you really want to fix, probably the fix would involve a scoring change to the BuiltinProvider to change it from a fixed relevance to something that increases as the user types more of the match.  I'd make the curve an arc that grows rapidly for the first few characters and asymptotically approaches a reasonably large value (somewhere near the history verbatim relevance value?).

My biggest question is why we're letting the built-in provider "stuff the ballot box". Simply by matching a single character - a very common first character - we push a stack of 'chrome://' entries, which contributes to pushing the others off the list. An improvement might be to push 'chrome://settings' at the same score, but the remainder at a greatly reduced score.

Because the BuiltinProvider is very simple and just gives a fixed score to everything.  Remember that this is basically how all the providers were designed initially, and we've only added complexity as needed.

Changing to account for how much of a match a user has typed, on its own, would probably bias toward the shortest builtin URLs, which is probably not right either.  We might want to rank-order a few at the top by hand (as you suggest) or something.

But again, I don't think this is really worth spending time on.  Typing a single character and then looking at the results, with no existing profile data to provide history suggestions, is a use case that basically only comes up in testing.  In cases with more input and/or more profile data, the results work better, and I'd focus our time on those.

I think a reasonable, low-investment change would be to make builtin provider score something lower, like 400 or 500 [1], in cases that the user hasn't yet typed the colon in the scheme.  Then search suggestions from the server will outweigh them.

I think this is equivalent to saying that it should score at 400/500 if the input type is UNKNOWN, and left at its current 800-something if the input type is URL.  Check this claim.

I would be reluctant to spending much more time worrying about this than the simple proposal I've suggested here.

By the way, if the user hasn't typed the beginning of the chrome URL "hostname", we do have an explicit rank order for suggestions:
chrome://chrome-urls/
chrome://settings/
chrome://version/

I think this is a good order.  The first gets you everywhere, and the second and third are common destinations.



[1] This is based on my interpretation of this table
https://cs.chromium.org/chromium/src/components/omnibox/browser/autocomplete_provider.h?sq=package:chromium&l=60
and the current metrics about usage.  Whether it should go above or below incomplete keyword search names is debatable.  I'm include to say "below", simply because showing keyword search names might prompt users to realize "hey, Chrome has a keyword search mode".  I don't feel strongly.

I think that's too conservative.  If I type "abou" or "chrom", I think BuiltinProvider results should be higher than 500.

If we're starting to talk about variable-length scoring, we might be overthinking this.  It's not worth much time.

You did note that comment 1 proposed variable-length scoring, right?  :)