Making a separate bug as requested in https://bugzilla.mozilla.org/show_bug.cgi?id=150025#c26 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 http://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.

While I respect Marco's point about this probably being separate from bug 150025 - bug 693808 only landed on Aurora 33. Are you sure you're still on 32? What's the value of this pref in about:config: browser.fixup.domainwhitelist.localhost ? It is true by default, and should prevent this from ever happening. The issue with the port is separate, I believe, and as Marco suggested might be related to a different bug (which I think has been backed out fairly recently, so it's possible that updating your copy of Aurora will fix all these things).

Also, what happens if you specifically type: "http://localhost/" and hit enter on that?

(In reply to :Gijs Kruitbosch from comment #1) > While I respect Marco's point about this probably being separate from bug > 150025 - bug 693808 only landed on Aurora 33. Are you sure you're still on > 32? I'm on Aurora 33, but the behavior is the same. > What's the value of this pref in about:config: > > browser.fixup.domainwhitelist.localhost > > ? It is true by default, and should prevent this from ever happening. It is true for me, but I still see the bug (In reply to :Gijs Kruitbosch from comment #2) > Also, what happens if you specifically type: "http://localhost/" and hit > enter on that? When I'm offline, I get redirected to http://www.localhost.com/ > The issue with the port is separate, I believe, and as Marco suggested might > be related to a different bug (which I think has been backed out fairly > recently, so it's possible that updating your copy of Aurora will fix all > these things). Ok. Filed bug 1049461 because I still see the issue in 33. I'm noticing now that if you switch steps 1 and 2, the problem goes away.

If you were already seeing this on 32 (pre-bug 693808) and the whitelist is set to true, you're hitting the fallback path where, if the hostname itself doesn't get a DNS hit, we do a search instead. That means it's not related to 693808, so I'm removing the dep... This implies that the DNS system tries to resolve "localhost" and fails. If you run this in the browser console in this (offline) state, what results do you get?: dnsService = Cc["@mozilla.org/network/dns-service;1"].getService(Ci.nsIDNSService); info = dnsService.resolve("localhost", 0); info.getNextAddrAsString(); and then repeat the last line until it throws an error along the lines of [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDNSRecord.getNextAddrAsString]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: debugger eval code :: <TOP_LEVEL> :: line 1" data: no] (I would expect, based on the above, that even the first response will be one of NS_ERROR_NOT_AVAILABLE, or potentially for the resolve call itself to return an error, but let's see...)

(In reply to :Gijs Kruitbosch from comment #4) > This implies that the DNS system tries to resolve "localhost" and fails. If > you run this in the browser console in this (offline) state, what results do > you get?: > > > dnsService = > Cc["@mozilla.org/network/dns-service;1"].getService(Ci.nsIDNSService); > info = dnsService.resolve("localhost", 0); > info.getNextAddrAsString(); > > and then repeat the last line until it throws an error along the lines of > > [Exception... "Component returned failure code: 0x80040111 > (NS_ERROR_NOT_AVAILABLE) [nsIDNSRecord.getNextAddrAsString]" nsresult: > "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: debugger eval > code :: <TOP_LEVEL> :: line 1" data: no] > > (I would expect, based on the above, that even the first response will be > one of NS_ERROR_NOT_AVAILABLE, or potentially for the resolve call itself to > return an error, but let's see...) Indeed. I get this the first time: [Exception... "Component returned failure code: 0x804b001e (NS_ERROR_UNKNOWN_HOST) [nsIDNSService.resolve]" nsresult: "0x804b001e (NS_ERROR_UNKNOWN_HOST)" location: "JS frame :: debugger eval code :: <TOP_LEVEL> :: line 2" data: no] which is different than when I'm connected (I get "127.0.0.1" the first time and an equivalent error afterwards)

(In reply to David Bruant from comment #3) > (In reply to :Gijs Kruitbosch from comment #2) > > Also, what happens if you specifically type: "http://localhost/" and hit > > enter on that? > When I'm offline, I get redirected to http://www.localhost.com/ > > > The issue with the port is separate, I believe, and as Marco suggested might > > be related to a different bug (which I think has been backed out fairly > > recently, so it's possible that updating your copy of Aurora will fix all > > these things). > Ok. Filed bug 1049461 because I still see the issue in 33. Separately, given the answers here, I suspect both that and this bug really still are identical to the original issue in bug 150025 - but it would be good to get to the bottom of it this time, and to keep the discussion in one place, at least for now, so let's keep going and resolve duplicates when we're 100% sure about what's going wrong here... > I'm noticing now that if you switch steps 1 and 2, the problem goes away. This is interesting... is this potentially to do with DNS caching? Specifically, if you switch these steps, are you maybe still restoring an existing tab or doing something else which means we cache the IP result for localhost? The DNS service, if it detects you're offline, will only return cached results, I think, from looking at: http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/nsIDNSService.idl#131 So it seems we need to teach the DNS service to also return local results when offline... not sure how easy that'll be, though (because how does it know a result is local? is just hardcoding localhost enough or can/should we do better?). :-\ needinfo for the following question: if you switch back to "working online" mode using the devtools or file menu checkbox, while the wifi is still dead, does that fix the issue?

(to be clear, this means the urifixup stuff really isn't at fault here, because even accessing http://localhost/ doesn't work because the actual DNS lookup is failing, which, err, obviously means that you're not going to be getting very far)

(In reply to :Gijs Kruitbosch from comment #6) > needinfo for the following question: if you switch back to "working online" > mode using the devtools or file menu checkbox, while the wifi is still dead, > does that fix the issue? When I open Firefox while the wifi is dead, the "working offline" checkbox isn't checked (so I'm implicitely online, regardless of not having wifi). When I check "working offline", interestingly, going to "localhost" does find the Apache server that runs in the background (instead of doing the search or telling me I'm supposed to be offline). However, when I try localhost:8888, Firefox tells me that I'm in offline mode, so I cannot connect to the Internet (I'll report that to the other bug if relevant). (In reply to David Bruant from comment #5) > (In reply to :Gijs Kruitbosch from comment #4) > > and then repeat the last line until it throws an error along the lines of > > > > [Exception... "Component returned failure code: 0x80040111 > > (NS_ERROR_NOT_AVAILABLE) [nsIDNSRecord.getNextAddrAsString]" nsresult: > > "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: debugger eval > > code :: <TOP_LEVEL> :: line 1" data: no] > > > Indeed. I get this the first time: > [Exception... "Component returned failure code: 0x804b001e > (NS_ERROR_UNKNOWN_HOST) [nsIDNSService.resolve]" nsresult: "0x804b001e > (NS_ERROR_UNKNOWN_HOST)" location: "JS frame :: debugger eval code :: > <TOP_LEVEL> :: line 2" data: no] I don't know how important it is, but I just noticed that in your error message, "nsIDNSRecord.getNextAddrAsString" is at fault while "nsIDNSService.resolve" is at fault in mine.

(In reply to :Gijs Kruitbosch from comment #6) > (In reply to David Bruant from comment #3) > So it seems we need to teach the DNS service to also return local results > when offline... not sure how easy that'll be, though (because how does it > know a result is local? is just hardcoding localhost enough or can/should we > do better?). :-\ What does "when offline" means? To some extent, when I have a local server listening to HTTP requests, the browser could consider I'm online. The problem might come from considering some interfaces (eth0, wlan0, etc.) and not others (lo) in some circumstances.

(In reply to David Bruant from comment #8) > (In reply to :Gijs Kruitbosch from comment #6) > > needinfo for the following question: if you switch back to "working online" > > mode using the devtools or file menu checkbox, while the wifi is still dead, > > does that fix the issue? > When I open Firefox while the wifi is dead, the "working offline" checkbox > isn't checked (so I'm implicitely online, regardless of not having wifi). Oh! That is surprising to me. I was under the impression that the offline state should sync with the wifi state. In this case, if you do an nslookup for localhost in the console, does that still work? :-\ I'm reaching the end of my vague knowledge/ideas about netwerk here, so I'm going to needinfo Patrick to see if he has any idea of what's wrong here...

Sounds similar to Bug 822573

The summary is the same as bug 339814.

daniel should be considered the online/offline expert. (tldr - its not all that useful)

Is this still an issue?

(In reply to Dragana Damjanovic [:dragana] from comment #14) > Is this still an issue? No it's not from what I can see on Firefox dev edition 37. Did something change?

(In reply to David Bruant from comment #15) > (In reply to Dragana Damjanovic [:dragana] from comment #14) > > Is this still an issue? > No it's not from what I can see on Firefox dev edition 37. Did something > change? Some parts have change in between these versions, but i cannot exactly tell what have fix it. If you cannot reproduce it anymore I will close this bug and if problem reappear, you can reopen it.