Last Comment Bug 66183 - Domain guessing results in incorrect "host not found" errors ("www." and ".com" incorrectly added)
: Domain guessing results in incorrect "host not found" errors ("www." and ".c...
Status: NEW
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: -- minor with 15 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
: 68534 90557 195824 236171 290749 317056 541600 581678 583634 587950 746852 764007 764388 1123071 1184894 (view as bug list)
Depends on: 115539
Blocks: 61685 63736
  Show dependency treegraph
Reported: 2001-01-22 04:13 PST by Henrik Gemal
Modified: 2016-04-12 05:18 PDT (History)
41 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Henrik Gemal 2001-01-22 04:13:12 PST
if you enter "" in the Location field and press Enter you eventual get
an error message saying:
" could not be found. bla bla."
if you press "Ok" the location field still says: ""

The error message should say "" NOT ""

Build 20010121
Comment 1 neeti 2001-01-22 10:06:28 PST
Adding to meta bug for error handling
Comment 2 Jesse Ruderman 2001-01-23 03:41:10 PST
Mozilla automatically tries adding a "www." whenever a second-level domain name 
you type into the location bar doesn't resolve (such as  It 
also does that, erroneously (bug 34943), when you cilck a link to  
(I'm not sure what happens if the second-level domain resolves but the server 
refuses the connection.)

It might be good to state what happened in the error message:
" could not be found (also tried".
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2001-02-19 12:22:02 PST
This also happens when we get a 301 Moved Permanently error with an invalid
hostname to be moved to.  See bug 68534 for an example.  There we get:

  HTTP/1.1 301 Moved Permanently

There is no such host, so we report that "" was not found. 
Since exists and can be accessed just fine, this is rather
Comment 4 Keyser Sose 2001-03-16 23:56:58 PST
*** Bug 68534 has been marked as a duplicate of this bug. ***
Comment 5 benc 2001-05-23 12:35:47 PDT
mass move, v2.
qa to me.
Comment 6 Jonas Jørgensen 2001-12-16 12:17:15 PST
Why does Mozilla try to add "www."? Why does it need to? Wouldn't the easiest
way to fix this simply be to disable the www-adding?

Personally I find the automatic www-thing very annoying. If a machine in a local
network called 'whatever' is down, why would I want Mozilla to try It's a waste of bandwith, and almost all important sites work
without www. anyway.
Comment 7 benc 2001-12-16 13:12:11 PST
jonasj: you don't need to make the same "I don't want this feature" comment in
every bug about the feature.

Create a bug that says "I think this feature should be disabled" or "I think
this should be off by default", etc.
Comment 8 Jonas Jørgensen 2001-12-16 15:35:08 PST
benc: It wasn't my intention to spam anyone - sorry about that. I just thought I
would ask whether there was some very good reason not to disable this feature
before I filed a bug on it. I filed bug 115539. Again, sorry about the spam.
Comment 9 Jonas Jørgensen 2002-01-05 15:21:21 PST
I believe fixing bug 115539 will also fix this. Marking dependent on 115539.
Comment 10 Jeremy M. Dolan 2002-01-14 14:25:37 PST
.com is also added to dialog. type in 'sdfdsf', mozilla says ''
could not be found. We *REALLY* should be saying:

   sdfdsf,, and could not be found. Please check the
   name and try again

Addition comment #10 has been brought to you by the coalition to stop auto www.
and .com'ing, and by viewers like you.
Comment 11 neeti 2002-03-25 08:37:12 PST
Comment 12 benc 2002-03-26 19:12:27 PST
qa to me.
tried to improve summary. feedback requested.
Comment 13 Daniel Wang 2002-10-07 01:05:06 PDT
dupe of bug 95390?
Comment 14 Chris Abbey 2002-10-07 18:00:43 PDT
Not likely.

95390 deals with http://noSuchHost/ spawning a key word search when it shouldn't
(whereas noSuchHost should). That problem goes away when you turn off "internet
keywords".  This problem focuses on the logic that would go off and look for and, and the error message
that is displayed when that lookup fails. This problem happens even with
"internet keywords" disabled.
Comment 15 benc 2002-12-13 08:19:42 PST
cc: cathleene, relates to user perception of performance

Reset milestone to --, please retriage.

If docshell has very inflexible error reporting, then there is a larger problem
that needs to be addressed, which is how to report back errors after many
different connection attempts have been made.

But on the surface, I think #3 is really on the money. The error should say what
was tried and failed, not just the last error because that is the way Necko and
DocShell report errors.

From a performance aspect, it should say that it searched for both, because if
you don't, then people think our DNS resolution is twice as slow as other
browsers, because we might be querying for records that are uncached on the
local DNS server.

Status shows some aspects of domain guessing's rollover, but not clearly enough
to keep a lot of very smart users (look at the names of the people who are
reporting these bugs!) from getting confused or frustrated.

Comment 16 Matthias Versen [:Matti] 2003-03-03 16:27:29 PST
*** Bug 90557 has been marked as a duplicate of this bug. ***
Comment 17 Matthias Versen [:Matti] 2003-03-03 16:27:41 PST
*** Bug 195824 has been marked as a duplicate of this bug. ***
Comment 18 davidvl 2003-03-04 03:23:36 PST
Why would Mozilla even search for .com domains with the prefix too? That is 
not at all what the user asked! An errrormessage stating 'sdfdsf,, 
and could not be found. Please check the name and try again' 
would therefore even be more confusing in my opinion.
The browser should not try to be smart in this case, because it would not help 
getting the user anyware.
Comment 19 Adam Lock 2003-03-04 10:24:12 PST
The www. & .com fixup is a feature which can be disabled by a pref. This bug
just covers what the error message should say if the feature is enabled.

Obviously if the user types 'foo' and gets an error that could not
be found it is confusing, however considering the prefs told Mozilla to try I don't believe it is *that* confusing. 

I would like the error to state all the urls, however it would require the
docshell track the list of URLs it has tried up until now for each fixup in
order to present this list to the user. This is why this bug has languished -
the code is significant for such a minor usability win.
Comment 20 Matthias Versen [:Matti] 2005-04-17 17:18:12 PDT
*** Bug 290749 has been marked as a duplicate of this bug. ***
Comment 21 2006-03-16 08:06:08 PST
this "feature" can be disabled by going to about:config and changing the value of "keywords.enabled" to "false".

is there a proper way to do that from the GUI?

i think this "feature" should be disabled by default and made explicit-only. if a user made a mistake in the address bar, indicate the mistake instead of opening some completely random site.

extremely irritating.
Comment 22 Chris Abbey 2006-03-16 08:22:18 PST
browser.urlbar.matchOnlyTyped I think is the pref you actually want zolba, however, at least in FF on the mac, it doesn't seem to work.
Comment 23 Chris Abbey 2006-03-16 08:26:14 PST
er, duh, as clearly documents, it is browser.alternate.*; which does work. In any case, this isn't keywords.
Comment 24 Jesse Ruderman 2007-08-24 22:21:48 PDT
This results in more problems than "just" an incorrect error message.  If I type "forums.mozillazineorg" (note the missing dot) into the address bar, press enter, then correct my typo and press enter again, I get another "host not found" error because of the "www." that Firefox added.
Comment 25 Graeme McCutcheon [:graememcc] 2008-01-31 11:43:28 PST
*** Bug 236171 has been marked as a duplicate of this bug. ***
Comment 26 Cameron McCormack (:heycam) 2008-11-10 16:28:02 PST
(In reply to comment #24)
> This results in more problems than "just" an incorrect error message.  If I
> type "forums.mozillazineorg" (note the missing dot) into the address bar, press
> enter, then correct my typo and press enter again, I get another "host not
> found" error because of the "www." that Firefox added.

Yeah, I can live with the misleading error personally (well, I rarely actually read the text of the Page Load Error page), but altering what I typed in the location bar (beyond adding the http:// and a trailing slash if necessary) is annoying.
Comment 27 Matthias Versen [:Matti] 2010-01-22 22:06:41 PST
*** Bug 541600 has been marked as a duplicate of this bug. ***
Comment 28 Matthias Versen [:Matti] 2010-07-24 12:13:02 PDT
*** Bug 581678 has been marked as a duplicate of this bug. ***
Comment 29 Nicolas Dumazet 2010-08-05 18:04:42 PDT
Let's try to add useful comments here.

I stumbled on this bug while setting up a front-end for my company, I know well what DNS configuration there is at this point, and who's serving which content.

* Reproducable for me on FF3.6.6 and 4.0b2. Distribution binaries (Mandriva) vs manual build does not affect the issue.
* I tried playing with browser.fixup.alternate.* parameters, it does not help.

Let me state also that "simple" tools such as curl, or wget "get the math" done properly ;) chromium 6 handles the case properly.

Looking at "dns or http" packets during FIRST lookup in Firefox:
  8.791980 -> DNS Standard query A
  8.808357 <- DNS Standard query response A xx.yy.xx.yy
  8.814991 -> DNS Standard query A
  8.831450 <- DNS Standard query response, No such name
  8.832966 -> DNS Standard query A
  8.849451 <- DNS Standard query response, No such name
  8.851029 -> DNS Standard query A
  8.859189 <- DNS Standard query response, No such name
  8.861028 -> DNS Standard query A
  8.877304 <- DNS Standard query response, No such name

The IP returned during the first lookup is correct. A http://ip-adress-here in firefox will get the job done.

If I retry LATER, the initial lookup
Comment 30 Nicolas Dumazet 2010-08-05 18:09:06 PDT
(sorry, submitted too soon).
If I retry LATER, the initial lookup is not done.
 1) either firefox cached the correct response.
 2) or it might have marked it as "invalid"/unresponsive and skips the lookup?

That's the best information I can provide at the moment. I understand that such bugs can be hard to reproduce; let me know if I can provide more details
Comment 31 Nickolay_Ponomarev 2010-09-04 17:28:32 PDT
*** Bug 583634 has been marked as a duplicate of this bug. ***
Comment 32 O. Atsushi (Torisugari) 2011-04-25 02:44:26 PDT
In summary, none of you want fix-up.

This bug reminds me bug 364667 and bug 402210. Is this removing the fix-up at all, or providing hyperlink(s) instead?
Comment 33 O. Atsushi (Torisugari) 2011-04-25 02:49:38 PDT
Or the location bar should go back to channel::originalURI, after redirecting?
Comment 34 Cameron McCormack (:heycam) 2011-05-08 17:24:07 PDT
There are two aspects to the bug: the location bar shouldn't change (beyond the normal addition of "http://" and a slash, and whatever other syntactic things it needs), and the error message shown in the "Server not found" page should list the original hostname and not one with "www." added.
Comment 35 Jani Ollikainen 2012-02-25 00:37:03 PST
I just now found this when trying to open up:

It has following hosts: has address
Host not found: 3(NXDOMAIN)

And Firefox tries to open up www one and I cannot open up perfectly valid url with Firefox.

So you are telling me that this is minor severity as the fixup.alternate feature can be disabled on about:config? Do you think that's proper way for people fix problems that they cannot open a webpage? I don't think many users will even realize that the problem is in their Firefox, not in their Internet connection or the site is down or something else. 

This is just ridiculous, over a century and it's still broken, even we get new Firefox all the time now. IMO failure to open perfectly valid URL with default settings is at least severity major, or maybe even a critical one.
Comment 36 Jani Ollikainen 2012-02-25 01:36:31 PST
Ok, maybe this wasn't the best place for that comment, but can't find better. That was written quickly in a little rage. Now it seems that the situation has gone like: lookup failed for some reason at first try, then Firefox tried with www and that also naturally fails. But reports that www as this bug says. 

Then my tinkering with fixup setting didn't do anything but just after that I tried again and Firefox did made a new lookup for and it worked and page was loaded.

So problem probably was just what's on the error message is miss leading and it made me think Firefox is totally broken :) So you could just fix the error message to avoid these kind of situations :D
Comment 37 Matthias Versen [:Matti] 2012-04-18 19:19:30 PDT
*** Bug 746852 has been marked as a duplicate of this bug. ***
Comment 38 A Capesius 2012-05-19 14:13:41 PDT
Another example:
Search for in address bar (or other random non-existent domain)
Firefox tries
Firefox tries
Firefox changes address bar to

1) The address entry should not be changed. Network issues may prevent access. Both and can be valid and point to different resources. Firefox should not assume www is correct.

2) The current method (as of FF 13) does not indicate on screen that both hosts were tried. It only indicates that was tried.

3) With the current method, a user may naturally remove the www and retry to request only to get the same error. This gives the impression that Firefox is not able to handle host names that are equivalent to the domain name.

I suggest handling be modified to try entered domain, then www if not specified by the user, then display user requested URL in the address bar. 

Usability and security tracking could be enhanced by indicating all hosts that were attempted in the failure page.
Comment 39 Matthias Versen [:Matti] 2012-06-12 15:19:36 PDT
*** Bug 764007 has been marked as a duplicate of this bug. ***
Comment 40 O. Atsushi (Torisugari) 2012-06-21 11:01:35 PDT
*** Bug 764388 has been marked as a duplicate of this bug. ***
Comment 41 Paul Silaghi, QA [:pauly] 2015-01-20 05:15:13 PST
*** Bug 1123071 has been marked as a duplicate of this bug. ***
Comment 42 Paul Silaghi, QA [:pauly] 2015-01-20 05:15:40 PST
*** Bug 317056 has been marked as a duplicate of this bug. ***
Comment 43 Jesse Ruderman 2015-01-20 14:53:16 PST
I've been finding blank tabs with addresses like lately, more often when I'm on an intermittent connection (such as the Mozilla MV office wifi).

I suspect there are a few bugs here:

* Firefox should only try prepending 'www' if the address was typed, not if it was a link click.
* Firefox should only try prepending 'www' if it gets a definitive failure, not if the DNS or HTTP request merely times out.
* Firefox should abandon the prepended 'www' URL if it gets a 404 response, and revert to showing the original error
Comment 44 Loic 2015-07-17 06:08:34 PDT
*** Bug 587950 has been marked as a duplicate of this bug. ***
Comment 45 Loic 2015-07-17 06:09:02 PDT
*** Bug 1184894 has been marked as a duplicate of this bug. ***
Comment 46 Loic 2015-09-27 15:45:40 PDT
*** Bug 1208896 has been marked as a duplicate of this bug. ***
Comment 47 Matias 2016-04-11 21:46:47 PDT
Confirmed on FF v45.0.1

If you try to use address bar to search on google (or other engine) strings like 'something.otherthing' it will try to go to the site something.otherthing (web page) instaed of search it on google.

Please firefox 10 years with this bug...on Chrome it doesnt happend. Thanks!

Note You need to log in before you can comment on or make changes to this bug.