150025 - Domain Guessing: Internet Keywords: exclude "localhost" from any "smart browsing features"

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[TK Kim]

When entered "http://localhost:5501" in the URL bar and enther, the browser will
give error message saying that it can't reach "www.localhost.com:5501".

Comment 1

[Greg K.]

TK, what Build ID are you reporting this against?

WorksForMe using FizzillaCFM/2002052918 (rv1.0.0). A "connection refused" error dialog is 
generated for [http://localhost:5501/].

What are your Autocomplete settings?

Changing Component to XP Apps: Autocomplete.

Comment 2

[Peter Aarestad]

I have had similar problems with Mozilla 1.0/PC. I type in

http://localhost:8080/

while at work (where I use a proxy), and I get a response back from the proxy!
At home (where I have no proxy), I've gotten a similar message to what the
reporter got. But

http://127.0.0.1:8080/

seems to work...

Comment 3

[TK Kim]

"127.0.0.1" works for me as well, but this still is a bug?

Comment 4

[Daniel Wang]

*** This bug has been marked as a duplicate of 95390 ***

Comment 5

[benc]

REOPEN:
This would have happened because your lookup for localhost failed. When this
happens, Domain Guessing most likely took over and made it "www.localhost.com",
although Internet Keywords may have had server logic that did the same thing, at
one time.

Comment 6

[benc]

I've reviewed all the bugs with localhost in the summary, and this seems to be
the first one where it becomes obvious that we should be excluding localhost
from all these clever features like Internet Keywords and Domain Guessing.

So I've changed the summary to reflect this. It is worth admiting here that in
many of the bugs that I have tried to move to the correct feature (is Internet
Keywords or Domain Guessing the cause?), that it is actually impossible to
determine which feature took control of your request.

But from the looks of it, Firebird is generating a lot of complaints, so we need
to think about controlling these features at the localhost level, as well as
changing other things like, doing IK when connection refused occurs.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

with bug 184433 fixed, I'd vote for this to be WONTFIX - DNS lookup for
localhost should never fail, and with that bug fixed we no longer do domain
guessing for errors other than host not found.

Comment 8

[benc]

I'm hoping it won't fix, but there are some incomplete problem reports that
suggest this might still need attention. 

How's this, lets leave it open until 1.8alpha, and see if it all the unexplained
problem reports are gone by then.

Comment 9

[alanjstr]

*** Bug 233002 has been marked as a duplicate of this bug. ***

Comment 10

[Jonathan Amir]

This happens to me even when the look up of localhost is fine but the server times out. see bug 320644.

Comment 11

[Annoyed]

Why on EARTH is this bug still open _6 YEARS_ after being reported? It really does beggar belief that what should be a two minute code change has been neglected, even in the latest build. In fact, I only signed up for a Bugzilla account solely to post this. Re: 7 - yes, DNS lookup will never fail, but if you specify a port a local webserver isn't listening on (eg http://localhost:8080/) it will timeout, and start trying www.localhost.com. It should NEVER do this. Exclude 'localhost' from the automatic .com and www. messing around. I'm away there's a config option I can turn it off for, but that would affect all sites, and it just needs to be done for localhost. FIX PLEASE. SIX YEARS AND ITS STILL NOT FIXED!

Comment 12

[alanjstr]

Anyone know where this code lives?

Comment 13

[benc]

Domain Guessing:

http://mxr.mozilla.org/seamonkey/source/docshell/base/nsDefaultURIFixup.cpp#403

403 PRBool nsDefaultURIFixup::MakeAlternateURI(nsIURI *aURI)

http://mxr.mozilla.org/seamonkey/source/docshell/base/nsDefaultURIFixup.cpp#794

794 nsresult nsDefaultURIFixup::KeywordURIFixup(const nsACString & aURIString, 
795                                             nsIURI** aURI)

If this is fixed, it should probably be implemented as one common function that masks a list of stuff. Not only localhost, but probably some kind of entries for Bonjour based stuff should be considered as well (still learning how that works...)

Comment 15

[Justin]

I would also love to see this exception implemented, especially because I run Firefox 3.6.10 on XP and even with the fixup disabled I STILL get the stupid www.localhost.com thus I'm forced to work with Internet Explorer - yuck yuck yuck.

And yes, it's a darn old problem, and the net is full of complaints. I'm also surprised nobody knowledgeable thought about writing an extension to fix the fixup...

Comment 21

[David Bruant]

Was about to file a duplicate. So obnoxious!

Comment 22

[taskman_theman]

I can't replicate the error anymore - this appears to be fixed in FF 30.0 on Windows 7.

Comment 23

[David Bruant]

I can reproduce in Firefox Aurora 32 (2014-07-19) on Linux. Steps to reproduce:
1) get offline (I turned off wifi, I imagine other ways will work too)
2) open Firefox (Aurora 32 in my case)
3) type "localhost" in the URL bar
4) validate (hit [Enter])

Actual result:
* Firefox tries to go to https://www.google.com/search?q=localhost&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fr:unofficial&client=firefox-aurora&channel=fflb (but fail because there is no network of course)

Expected : 
* Connects to localhost


If step 3 is changed to typing "localhost:8080" (it's a common practice for web devs to have a local server on a given port like 8080), the URL bar decides to go to "http://www.localhost.com:8080/" which isn't the intended behavior. There is no reason to prefix with "www".

For whatever reason, step 1 is important to reproduce the bug. The fact that the behavior of the URL bar is different based on an external factor is concerning in my opinion and might deserve its own bug.

needinfo'ing Yoric to ask where to look at to fix this, because I think it's the sort of code you're familiar with. Feel free to pass along if you don't know.

Comment 24

[David Teller [:Yoric] - still alive but not very active]

I don't really know who's working on this. Deflecting to ttaubert, for further dispatch.

Comment 25

[Tim Taubert [:ttaubert] (inactive)]

Marco, do you know what's happening here?

Comment 26

[Marco Bonardo [:mak]]

(In reply to David Bruant from comment #23)
> I can reproduce in Firefox Aurora 32 (2014-07-19) on Linux. Steps to
> reproduce:
> 1) get offline (I turned off wifi, I imagine other ways will work too)
> 2) open Firefox (Aurora 32 in my case)
> 3) type "localhost" in the URL bar
> 4) validate (hit [Enter])
> 
> Actual result:
> * Firefox tries to go to
> https://www.google.com/search?q=localhost&ie=utf-8&oe=utf-8&aq=t&rls=org.
> mozilla:fr:unofficial&client=firefox-aurora&channel=fflb (but fail because
> there is no network of course)
> 
> Expected : 
> * Connects to localhost

please file this as a separate bug and block bug 693808 with it. It's strange cause localhost should be whitelisted. Regarding localhost:8080 it's hard to tell if related to that one or to bug 354493

Comment 27

[David Bruant]

(In reply to Marco Bonardo [:mak] (Away 15-31 Aug) from comment #26)
> (In reply to David Bruant from comment #23)
> > I can reproduce in Firefox Aurora 32 (2014-07-19) on Linux. Steps to
> > reproduce:
> > 1) get offline (I turned off wifi, I imagine other ways will work too)
> > 2) open Firefox (Aurora 32 in my case)
> > 3) type "localhost" in the URL bar
> > 4) validate (hit [Enter])
> > 
> > Actual result:
> > * Firefox tries to go to
> > https://www.google.com/search?q=localhost&ie=utf-8&oe=utf-8&aq=t&rls=org.
> > mozilla:fr:unofficial&client=firefox-aurora&channel=fflb (but fail because
> > there is no network of course)
> > 
> > Expected : 
> > * Connects to localhost
> 
> please file this as a separate bug and block bug 693808 with it. It's
> strange cause localhost should be whitelisted. Regarding localhost:8080 it's
> hard to tell if related to that one or to bug 354493
Filed bug 1049444