Can someone explain the logic behind submitting a string in chrome's "address" bar when auto-completion is turned on?

I was surprised to see it performs validation of the string inputted before even trying a network connection but I can see a few reasons why it has been implemented like that.

The omnibox allows for easy entries of either navigation URLs or search queries.  We need to decide which it is by inspecting it.  "0" / "0.0.0.0" is a reserved IP address, so the omnibox used to consider it not a valid domain name, and do search queries instead.  They changed behavior a while back, to treat it as a domain name, since some funky tools like to use it as an alias for 127.0.0.1.  You're using a very old version of Chrome, nearly 8 months old.  Update it and the behavior will change here.  Also note that a version that old may well have known security vulnerabilities, so you really make sure you keep it up to date.

Closing the issue, as it's already been fixed.

Comment 2 is not quite correct.  The behavior of "0" differs from "0.0.0.0".  The latter will navigate by default; the former will search by default.  Comment 0 talks about the former, so it is correct in its description of current behavior.

It is plausible that we could decide that "http://0" should navigate by default.  We haven't so far because usage of 0.0.0.0 is already so rare that a simple bandaid to allow people to use it that way seemed sufficient.  Combining it with writing the IP as a decimal number instead of a dotted quad combines two very obscure navigation methods.

OTOH, if someone types "http://0", it seems unlikely that they would prefer to search rather than navigate.  So perhaps we should treat "0" as we treat decimal numbers >= 16777216, and search by default but navigate if someone gives us more clues that it's an explicit navigation.

The downside to this is that today, a port number is sufficient to trigger this, so e.g. "0:1" would navigate.  I'm concerned that's not the right default for that input.  Similarly, "0/" would navigate.

So I wonder if we should treat an explicit scheme as a stronger signal of a desire to navigate than, say, a port number.

This is all kind of a mess.  Reporter, can you just use 0.0.0.0 or (better) 127.0.0.1?

To answer comment #3, sure I can use other local interface(s) aliases, and I am since I can't use the easiest one to type but I like to think that a world class browser developed by a smart bunch like you should not break things that worked since the dawn of time.

I have no doubt it's indeed a rare use case but some people do use it and they may be as frustrated as I am to find out it doesn't work in chrome.

It's the way my finger memory know how to type 127.0.0.1 and I use it everywhere else so I'm unlikely to remember that something that takes me less than 1 second to type, will not work before I realize I'm in front of something I didn't expect (google search results).

Finally I would like to say that it's always very satisfying to use 0 instead of 0.0.0.0 or even worse 127.0.0.1, we're talking about saving 6 to 8 keystrokes, and that's a lot! In fact, it does not even make sense to waste key strokes by using 0.0.0.0 or 127.0.0.1 when typing 0 will provide the same results.

If this gets fixed in chrome I will do my best to advocate the use of 0 in the browser.

If you do one or two typed navigations to "0.0.0.0", then "0" should inline-autocomplete to that, and you should be in the scenario where you can hit "0" and enter to get what you want again.

That's probably the best answer here, since making it so that "0" on its own will navigate by default isn't right, and making it so that "http://0" and similar will navigate will still incur more than six extra keystrokes, so that's not really more convenient than 0.0.0.0.

Clarifying summary line and revising priority.

It's clear no one actively working on the omnibox will bother fixing this; patches are invited from others.

Well, they're invited if they do The Right Thing, but I don't know that it's clear what The Right Thing is.  From comment 3, I think it's something like "Allow a bare zero to navigate with explicit intent" and "make http:// give explicit navigation intent, but not :1".  This is still hand-wavey.

Since chromium is at its core an HTTP client, I think the right thing to do would be to honor client requests that explicitely ask for an HTTP document (i.e.: "http://0")

As for the "0" search query, I agree it might not be clear what the right thing to do in this case is as the omnibox is not primarily an address bar.

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

In my opinion, this is enough of a corner case to not be worth a change and thus even a small risk of complicating or breaking some other behavior.

nicolas.couture:

> I like to think that a world class browser developed by a smart bunch like you should not break things that worked since the dawn of time.

I appreciate the compliment, but this isn't really a matter of smart, it's a matter of trading off value for complexity. The logic for deciding whether an input intends a search or a navigation is one of those things that's more complex than you image. See the following for just a taste. :)

https://cs.chromium.org/chromium/src/components/omnibox/browser/autocomplete_input.cc?l=178-476&rcl=fcebb0df660dc2bc21129956691bb70dc1f4a9ed