New issue
Advanced search Search tips

Issue 724490 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 362356
Owner: ----
Closed: May 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Omnibox searches for test.test / test.invalid / test.localhost / test.lan / test.local

Reported by f.fich...@googlemail.com, May 19 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Enter one of the specified domains into the omnibox
2. hit enter

What is the expected behavior?
Chrome should check for these domains whether there exists a DNS entry and then load that site if not it could either show a error message that the entered domain is not registered or search for the entered "wrong" domain.

What went wrong?
Chrome searches for the valid url instead of contacting the default DNS resolving mechanism first.

Did this work before? N/A 

Chrome version: 58.0.3029.110  Channel: stable
OS Version: OS X 10.12.4
Flash Version: Shockwave Flash 25.0 r0

The mentioned TLDs aren't officially official but IETF recommends them in RFC 2606 ( https://tools.ietf.org/html/rfc2606 ) for testing and documentation purposes. As such also the following TLDs are widely used: localhost, local (for mDNS resolved servers), lan, ...

I have only found discussions of people wondering why none of the most widely used TLDs for testing are not working. 

I haven't found any hardcoded list of existing TLDs but I found out that Chromium is using the PSL but the .local TLD got removed from that list as it is not a public suffix.
 

Comment 1 by mmenke@chromium.org, May 19 2017

Components: -Internals>Network UI>Browser>Omnibox
Unfamiliar with the omnibox logic, but the DNS layer does hard-code .localhost to be 127.0.0.1, for security reasons.
You are correct that .local is not a known TLD.  Chrome navigates using the PSL because we need to know synchronously what to do before navigating; DNS lookups can take long amounts of time, delaying every potentially-navigable search (which is the majority of them), so that's not an option.

However, Chrome should show you an infobar after you search, allowing you to teach the browser that this is a navigation.  

Relevant bugs:
Bug 104638 - Any one .local navigation should teach Chrome that all .local entries are navigations
 Bug 247848  - Infobar may not appear due to prerendering

Duping against  bug 362356  which is basically a similar complaint here, but the core behavior ("assume .local is always a navigation") is WontFix.

Comment 3 by mmenke@chromium.org, May 19 2017

Mergedinto: 362356
Status: Duplicate (was: Unconfirmed)
(Oops, thanks)

Sign in to add a comment