anowlcalledjosh@ Thanks for the Feedback.

Able to reproduce the issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Canary 66.0.3355.0 and Stable 64.0.3282.186.

On typing chrome://set in the omnibox, can observe that it is not getting auto completed.

This is a Non-Regression issue as this behavior is observed from M60 Chrome builds. 
Hence marking this as Untriaged for further updates from Dev.

Thanks..

This sounds like a nice enhancement. It seems a very safe bet that chrome://set is going for chrome://settings.

It does currently *tab-complete* to "chrome://settings" which is similar (an extra key to hit). 

I think what this is really asking for is to eliminate the "(matches_.size() == 1)" check in BuiltinProvider::Start().

This has been present since mpearson originally implemented inlining for this provider, and was never really tested; see https://bugs.chromium.org/p/chromium/issues/detail?id=226825 , especially comment 16.

However, note that if you just blindly remove this without any other scoring tweaks, you'll likely hurt quality, because suddenly BuiltinProvider will be scoring at least one match at 1250 even for the inputs "a" or "c".  What you may want instead is something like:

* Allow all inlineable matches to be default at all times, but
* Give scores based on the fraction of them that users have typed.  Adjust scores by hand so that the score for about:settings is lower than any other provider for "a", and high enough to beat the search what-you-typed result for "about:s".  This might just mean a step function for after the user types a scheme + one more letter?  I dunno.

I think there's a better, easily solution that the complicated scoring one suggested here.  The reason chrome://settings isn't autoocompleted in the omnibox, not even for "chrome://set", is because we have multiple suggestions with that prefix.  We never autocomplete if there are multiple possibilities (else how would you pick just one?).

In this case, though, the multiple possibilities are:
* chrome://settings
* chrome://settings/autofill
* chrome://settings/clearBrowserData
It's clear that one is a prefix of the rest.  We should allow autocompletion to that one.  If users want a longer one, they can press the right arrow or end button and then type more.

In other words, I agree with the suggestion in the original bug report ("if all suggestions share a common prefix, autocomplete that prefix."), and think the more complicated solutions in comment #4 are not necessary.

Common prefix doesn't necessarily work:

chrome://appcache-internals
chrome://apps

Type "chrome://ap" and you get another 'p' autocompleted, but the resulting page can't be navigated to.  We should never inline-autocomplete to a broken result.

Were you instead suggesting "select the shortest match from the group, see if it is a prefix of all other matches, and if so autocomplete to it"?

(BTW, I still think my more complicated answer would have other ranking benefits beyond just solving this issue, and would have less step-functiony sort of behavior, and thus would be good for both UX and maintenance in the future.)

Sorry, I mis-stated my suggestion.  I meant "It's clear that one is a prefix of the rest.  We should allow autocompletion to that one."

I think it's a simple solution.  I don't think we should spend much time thinking about / messing with by hand the scoring of chrome:// URLs.  It's not worth the time.  I have two concerns about the scoring proposal suggested in comment #4--reasons why it might not work as described without even more work--so if someone actually wants to / plans to implement that, please talk with me first.  (Likewise, It's not worth the time to discuss all the concerns unless someone is actually going to go down that complicated scoring path.)

+1 for a simple solution

mpearson: Do I understand correctly that your proposal is to just modify BuiltinProvider::Start() to change the logic at the end to be something like:

  if (!HistoryProvider::PreventInlineAutocomplete(input) &&
      !matches_[0].inline_autocompletion.empty()) {
    if (matches_.size() == 1) { 
      matches_[0].relevance = 1250;
      matches_[0].allowed_to_be_default_match = true;
    } else {
      const size_t index = GetIndexOfMatchThatIsPrefixOfAll();
      if (index != -1) {
        matches_[index].relevance = 1250;
        matches_[index].allowed_to_be_default_match = true;
      }
    }
  }

Yes, that's what I was thinking of.

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

commit f45666be94f00d58a33f450789a0b33b4316edeb
Author: Justin Donnelly <jdonnelly@chromium.org>
Date: Fri Apr 13 17:04:36 2018

[omnibox] Have the builtin provider inline autocomplete more aggressively.

This is primarily motivated by the chrome://settings case, which
currently is never autocompleted because the builtin provider only
autocompletes in cases where there is a single suggestion. And any input
that matches chrome://settings also matches subpages such as
chrome://settings/autofill.

However, this change also affects one other current case,
chrome://chrome and chrome://chrome-urls. The former will now be inline
autocompleted.

Bug:  816450 
Change-Id: I9671033c27c7f8bab1f7cfcbb2989e507e1aeee5
Reviewed-on: https://chromium-review.googlesource.com/976397
Commit-Queue: Justin Donnelly <jdonnelly@chromium.org>
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550657}
[modify] https://crrev.com/f45666be94f00d58a33f450789a0b33b4316edeb/components/omnibox/browser/builtin_provider.cc
[modify] https://crrev.com/f45666be94f00d58a33f450789a0b33b4316edeb/components/omnibox/browser/builtin_provider.h
[modify] https://crrev.com/f45666be94f00d58a33f450789a0b33b4316edeb/components/omnibox/browser/builtin_provider_unittest.cc

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

commit f45666be94f00d58a33f450789a0b33b4316edeb
Author: Justin Donnelly <jdonnelly@chromium.org>
Date: Fri Apr 13 17:04:36 2018

[omnibox] Have the builtin provider inline autocomplete more aggressively.

This is primarily motivated by the chrome://settings case, which
currently is never autocompleted because the builtin provider only
autocompletes in cases where there is a single suggestion. And any input
that matches chrome://settings also matches subpages such as
chrome://settings/autofill.

However, this change also affects one other current case,
chrome://chrome and chrome://chrome-urls. The former will now be inline
autocompleted.

Bug:  816450 
Change-Id: I9671033c27c7f8bab1f7cfcbb2989e507e1aeee5
Reviewed-on: https://chromium-review.googlesource.com/976397
Commit-Queue: Justin Donnelly <jdonnelly@chromium.org>
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550657}
[modify] https://crrev.com/f45666be94f00d58a33f450789a0b33b4316edeb/components/omnibox/browser/builtin_provider.cc
[modify] https://crrev.com/f45666be94f00d58a33f450789a0b33b4316edeb/components/omnibox/browser/builtin_provider.h
[modify] https://crrev.com/f45666be94f00d58a33f450789a0b33b4316edeb/components/omnibox/browser/builtin_provider_unittest.cc