if you enter "gemal1.dk" in the Location field and press Enter you eventual get
an error message saying:
"www.gemal1.dk could not be found. bla bla."
if you press "Ok" the location field still says: "gemal1.dk"
The error message should say "gemal1.dk" NOT "www.gemal1.dk"
Adding to meta bug for error handling
Mozilla automatically tries adding a "www." whenever a second-level domain name
you type into the location bar doesn't resolve (such as http://cmc.edu). It
also does that, erroneously (bug 34943), when you cilck a link to cmc.edu.
(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:
"gemal1.dk could not be found (also tried www.gemal1.dk)".
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 "www.intelegence.com" was not found.
Since www.intelegence.com exists and can be accessed just fine, this is rather
*** Bug 68534 has been marked as a duplicate of this bug. ***
mass move, v2.
qa to me.
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
www.whatever.com? It's a waste of bandwith, and almost all important sites work
without www. anyway.
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.
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.
I believe fixing bug 115539 will also fix this. Marking dependent on 115539.
.com is also added to dialog. type in 'sdfdsf', mozilla says 'www.sdfdsf.com'
could not be found. We *REALLY* should be saying:
sdfdsf, sdfdsf.com, and www.sdfdsf.com 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.
qa to me.
tried to improve summary. feedback requested.
dupe of bug 95390?
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
http://noSuchHost.com/ and http://www.noSuchHost.com/, and the error message
that is displayed when that lookup fails. This problem happens even with
"internet keywords" disabled.
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.
*** Bug 90557 has been marked as a duplicate of this bug. ***
*** Bug 195824 has been marked as a duplicate of this bug. ***
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, sdfdsf.com,
and www.sdfdsf.com 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.
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 www.foo.com could not
be found it is confusing, however considering the prefs told Mozilla to try
www.foo.com 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.
*** Bug 290749 has been marked as a duplicate of this bug. ***
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.
browser.urlbar.matchOnlyTyped I think is the pref you actually want zolba, however, at least in FF 126.96.36.199 on the mac, it doesn't seem to work.
er, duh, as http://www.mozilla.org/docs/end-user/domain-guessing.html clearly documents, it is browser.alternate.*; which does work. In any case, this isn't keywords.
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.
*** Bug 236171 has been marked as a duplicate of this bug. ***
(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.
*** Bug 541600 has been marked as a duplicate of this bug. ***
*** Bug 581678 has been marked as a duplicate of this bug. ***
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 myserver.company.co.jp lookup in Firefox:
8.791980 -> DNS Standard query A myserver.company.co.jp
8.808357 <- DNS Standard query response A xx.yy.xx.yy
8.814991 -> DNS Standard query A www.myserver.company.co.jp
8.831450 <- DNS Standard query response, No such name
8.832966 -> DNS Standard query A www.myserver.company.co.jp
8.849451 <- DNS Standard query response, No such name
8.851029 -> DNS Standard query A www.myserver.company.co.jp
8.859189 <- DNS Standard query response, No such name
8.861028 -> DNS Standard query A www.myserver.company.co.jp
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 myserver.company.co.jp lookup
(sorry, submitted too soon).
If I retry LATER, the initial myserver.company.co.jp 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
*** Bug 583634 has been marked as a duplicate of this bug. ***
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?
Or the location bar should go back to channel::originalURI, after redirecting?
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.
I just now found this when trying to open up: http://minimalmac.com/post/18189678921/tv-is-broken
It has following hosts:
minimalmac.com has address 188.8.131.52
Host www.minimalmac.com 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.
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: minimalmac.com 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 minimalmac.com 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
*** Bug 746852 has been marked as a duplicate of this bug. ***
Search for dsadqwqdqdada.com in address bar (or other random non-existent domain)
Firefox tries dsadqwqdqdada.com
Firefox tries www.dsadqwqdqdada.com
Firefox changes address bar to www.dsadqwqdqdada.com
1) The address entry should not be changed. Network issues may prevent access. Both dsadqwqdqdada.com and www.dsadqwqdqdada.com 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 www.dsadqwqdqdada.com 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.
*** Bug 764007 has been marked as a duplicate of this bug. ***
*** Bug 764388 has been marked as a duplicate of this bug. ***
*** Bug 1123071 has been marked as a duplicate of this bug. ***
*** Bug 317056 has been marked as a duplicate of this bug. ***
I've been finding blank tabs with addresses like http://www.t.co/aQVI2kvMxu 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
*** Bug 587950 has been marked as a duplicate of this bug. ***
*** Bug 1184894 has been marked as a duplicate of this bug. ***
*** Bug 1208896 has been marked as a duplicate of this bug. ***
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!