New issue
Advanced search Search tips

Issue 30636 link

Starred by 74 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2010
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

chrome does a search when i want to open a website on a custom TLD

Reported by, Dec 17 2009

Issue description

Chrome Version       : (Official Build 33928) running under Mac OS X
URLs (if applicable) :,, ...
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: OK
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK

What steps will reproduce the problem?
1. enter a URL which your DNS server knows about, but chrome doesn't recognise without a URL scheme. eg: ""
2. press enter

What is the expected result?

A DNS lookup is performed on "example.pre", and upon successful result the page ""

What happens instead?

A google search for "example.pre" is opened with a drop down box "did you mean"

Please provide any additional information below. Attach a screenshot if

At our web development company, we have a development copy of all of our clients websites running in our datacentre which is accessed via ".pre" 
as a suffix, and all of our developers have a personal copy of the website available via ".dev-bob.pre" as a suffix. Our local DNS server as well as our 
VPN setup is configured to direct the fake "pre" TLD to the correct server.

This has worked perfectly for us for years with every web browser, but in Chrome we must explicitly enter "http://" before the domain name, which 
is frustrating since we have literally thousands of domain names, and often need to type them in quickly (such as while on a phone call with the 
Status: WontFix
This is by design, since otherwise every search from the omnibox would take the 
(sometime substantial) latency hit of doing the DNS query first (I can't find a single 
obvious dup, but there are several related WONTFIX bugs).

If you just type the trailing '/', then the search will be bypassed.
 Issue 33928  has been merged into this issue.
 Issue 50051  has been merged into this issue.
 Issue 52586  has been merged into this issue.

Comment 5 by, Dec 20 2010

A custom TLD with trailing slash triggers a search for me (Chrome 8.0.552.224 on Windows 7 64bit). If this is by design my opinion is that it's a poor design choice as many developers do their work on custom TLDs. I'll keep to Firefox for now.

Comment 6 by, Jan 22 2011

Yeah, the trailing slash doesn't help here either. FWIW, http://<localhostname>:port/ fails terribly.

Comment 7 by, Jan 22 2011

Any other suggested workarounds for this bug?

Comment 8 by, Jan 22 2011

Hrm, disregard, this occurred because the port in question was invalid (>2^16), which looked very much valid at first glance.

Comment 9 by Deleted ...@, Feb 10 2011

Wow, this is a show stopper at our company. Back to corporate standard IE it is.  :-(

Comment 10 by Deleted ...@, Feb 11 2011

How can this be by design? How hard is it for chrome to recognise that a solid string that contains some text followed by a period followed by another string is almost always going to be an address and not a search.

And no the / doesn't always work. A workaround is not a solution, it's an acceptance of poor design.

Firefox does this perfectly, and isn't exactly slow at it. Safari even has a plugin that changes it to a search/address, and even the guy who coded that was smart enough to know randomtext.tld is an address not a search.
I agree, this is an annoying problem that I consider a bug.  And the trailing slash workaround doesn't work for me either.

One DNS lookup when the return is pressed doesn't seem a high a price to pay for having basic functionality work as expected, as it does in other browsers.  If latency is really a problem, do the lookup in parallel with the Google search and use the Google result only if the DNS finds nothing.

Could we at least make this behaviour a configurable option?
 Issue 75449  has been merged into this issue.
Add me to the list of unhappy developers.
All you have to do is...
if (([a-zA-Z]?[0-9a-zA-Z-]*)\.([a-zA-Z]{1,4})) {
     do dns check
} else {
     search google
You can at least add flags or some advanced options to "Enable DNS check for the following custom TLD's:" [Button=Add Custom TLD] or just a text field (e.g. [ njb, local, lh, pre ])

Comment 15 by Deleted ...@, Jun 1 2011

I agree and would like to see a configuration option to specify a list of custom TLDs for bypassing the search.
It is a show stopper in our company too.

But it is not that easy to detect a period between 2 solid strings. Our DNS resolver searches the domain for a given hostname too so one can type both "ping wiki" or "ping" to resolve correctly, so typing simple "wiki" to a browser is expected to work also. Firefox does this just fine and fast enough.

I also noticed once typed with trailing "/", chrome stores the "" string to its browsing history and after that this history is being searched in advance to anything else and so typing "wiki.cpnet" and even "wiki" make chrome to show the correct page. 

Comment 16 by, Aug 10 2011

Same issue with single-name domain names. At least I know now about the trailing "/" workaround. Before, I was always pre-pending "http://". Still, most companies have internal hostnames which are often single-name (no TLD). There must be a compromise here.

Comment 17 by Deleted ...@, Aug 20 2011

There's no reason for Chrome to need to require / to check the hosts file. If I set up my hosts file to direct 'localhost' to, then that's exactly what my browser should do when I type 'localhost' into the address bar. The host name is not '/localhost'. Chrome is the only browser that requires this, and it appears it's just to get you to go to Google's search page. I'm a developer, and this is giving me a reason not to use Chrome.
As many have already said, this is highly irritating and would be trivial to fix. Many developers run local domains and this is a nuisance!

Comment 19 by Deleted ...@, Sep 27 2011

So Annoying :(
I think a simple pattern match should work, as many have said.

Or, when that little "did you mean 'HTTP://'?" comes up, give me an option to "remember this TLD".

Also, please make Chrome actually friggin' remember the custom TLDs that I use all the time. When I'm on "" and I manually change the URL to "", I DON'T WANT TO FRIGGIN SEARCH FOR IT AND THAT SHOULD BE REALLY FRIGGIN OBVIOUS. Frig.

I love Chrome for thinking out these sorts of details. For keeping the tabs the same width while I'm closing them so that I can work quickly. These details matter and Chrome is so loved because it cares about them. Closing this issue as WontFix is unacceptable. It makes Chrome seem stupid and underthought and just frustrating.
^^ Amen

Comment 22 by, Nov 21 2011

Please, give us something along these lines... even if it's hidden and obtuse, as long as its functional and can be configured.
Perhaps the DNS lookup and Google search could be performed simultaneously and if there is a DNS match, display that page instead of a search.

At least I my case, I have less than 1 millisecond latency to the DNS server, so performance is a non-issue.

Again, this is a show stopper bug for me and many others. It stokes Chrome off the list of browsers I will even consider using.

Comment 24 by, Nov 21 2011

@23 I think chrome essentially already does that, because if what you had entered yields a response, chrome provides the slide-down link. Since Chrome already has a facility whereby it decides if what you entered is supposed to be a search or URL, I'd like to simply see that decision point be configurable to where we could enter TLDs to consider indicative of URLs, or some pattern, etc.
Yes, I agree with the above: On top of the "Did you mean to go to this address" there should be some sort "remember this TLD" functionality. OR, just a setting in Chrome where you can set a list of custom TLDs.

I have many sites set up locally with a custom Dev domains and when it does a search instead of going to the site it's rather annoying.

Comment 26 by, Dec 8 2011

How hard can it be to expose the list of accepted TLD's through one of the about:pages ?!
fwiw, the trailing slash workaround does not work if you need to specify a directory after the hostname,
even if using a trailing slash on the end of the directory. filed  bug 107140  for that.

Comment 28 by, Dec 22 2011

I can't believe there's even a doubt here.

Answer is simple.  Multi-thread a DNS lookup while conducting the search for instant results.  When the DNS returns, add it to the list of results at the top of the omni box results.
@24 my DNS server has a latency of about 1 millisecond, and is running on a Xeon class server that's usually idle (behind a firewall, only a handful of people can access it).

Since takes chrome a few seconds to suggest the actual domain name typed in, clearly it doesn't do a DNS lookup immediately. It's waiting for something else to finish first.

I suggested chrome could do a DNS lookup immediately and at the same time as the google search. Since google's servers are physically distant and the search is computationally intensive, any local DNS server is going to respond long before the google search is ready. If that happens, simply display the actual DNS result instead of a search.

I feel like this would drastically reduce the regularity people are seeing a google search instead of the website typed in (currently multiple times a day for me and my colleagues, as we have close to 10,000 domains under our custom TLD and new ones created every day), and make the browser usable.
I think at least an option for developers should be considered, since most devs won't care much about the latency caused by a DNS lookup.

Comment 31 by, Jan 26 2012

Not searching the local domain before doing a google search is unacceptable. Pretty much everyone who uses Chrome at work will run into this issue. This does not help Chrome in the eyes of Corporate/Enterprise business.
Seriously, if FF ever gets their memory back under control, I'd switch back just for this.
unbelievable. does noone at google use custom TLDs during development? I think it says a lot that many posters here are a hair's breath away from firefox just because of this. it's been almost 2.5 years since the OP. Can the Chrome dev team please provide a way to configure custom TLDs?

Comment 34 by Deleted ...@, May 7 2012

If you need custom TLDs because say you're developing with a server like POW.  You could try this:
All the comments about doing DNS AND searching are pointless. 
The DNS query will always return first unless it's a fail to resolve. In which case, you can expect to be delayed. Why ? Because : The search will have to do a DNS lookup to get to google. So you fire off 2 DNS lookups, one comes back with your internal address and the other is google, at that stage you know there is no need to search. Doesn't matter about performance of DNS server because both are likely served by the same server.

What concerns me is how the browser decides if it's a valid tld or not. Does the browser contain a list? If so we are all going to need to upgrade browser every time a new tld name is released under the proposals for allowing anyone to register whatever tld they want. Hopefully Google will realise that all of a sudden they have to fix this issue they've been ignoring for 3 years.
Or, will chrome start searching for every URL to see if it's on a central list of valid tld names. Which raises more security, performance and private LAN concerns.
I am now having the problem where search is ALL that happens for local domain sites

domain: example.local
url as typed: http://site.machine.example.local/subfolder/

as you can see both "http://" and the trailing "/" have been typed on a fully qualified domain machine name.

All that happens is a failed public Google search.

The protocol should ALWAYS be, if the URL is lead with a search indicator "?query" then search, else check DNS/proxy. if no result perform final search.

Currently this is not meeting security requirements.
The proposed solution does not work, hence "wontfix" needs to be changed back to mark this as an open issue!

Comment 38 by, Jan 16 2013


I have created a workaround for this bug by utilizing Chrome's search engine settings. Instead having your browser sending search queries typed in the address bar to Google, you can set it to go to my PHP script, which will basically make Chrome act the way it ought to

For this workaround to function, my script has to be hosted on a web server. I am hosting the script on my own server for public use, but if you already have your own web server, I recommend hosting it yourself. That way, you don't have to rely on me to keep my server online, you can choose your search engine, and you will have faster load times. The script is attached if you decide to host it. But if you don't have a web server, the version I am hosting should be fine.

Anyway, to enable this workaround, right-click the omnibox and click "Edit search engines...". Scroll to the bottom of all the search engines to add a new one. Set the name and keyword to whatever you want, then set the URL box to "[YOUR TLDS HERE]" (if you are self-hosting the PHP script, replace "" with the URL to your copy of the script obviously).

Replace "[YOUR TLDS HERE]" with a list of all the custom local TLDs you use, separated by "%7C". So for example, if my network used the TLDs "local", "dev", and "wiki", then my URL would be "" (if you want, you can also use regex patterns to define TLDs; just be sure to properly URL-encode everything).

Once you have the URL finished, hit Enter. The search engine you just typed in will likely disappear, so scroll up to find it in the list (protip: it's alphabetical). Once you find it, hover your mouse over the URL and click "Make default", and that should cover it. URLs with custom TLDs should work now, and normal search queries should go to Google still. Huzzah!

P.S. If you want to use a different search engine than Google for normal search queries, you will have to host the script on your own web server. Open the script in a text editor and there will be instructions on how to change the search engine.
1.6 KB View Download

Comment 39 by, Mar 25 2013

Labels: -Area-Misc Cr-UI-Browser-Omnibox
I wonder whether we have considered the following (comment 20):

> when that little "did you mean 'HTTP://'?" comes up, 
> give me an option to "remember this TLD".

Given the way eTLD list is handled (pre-compiled hash is used), we need to have a secondary look-up table (and have to store the list in Pref).  
Labels: Restrict-AddIssueComment-EditIssue
Yes, that's bug 104638.

This bug has been WontFixed for years, please avoid adding more comments.  As with the afore-mentioned bug, there are other bugs that better cover specific related enhancements.

Sign in to add a comment