Open Bug 150025 Opened 22 years ago Updated 2 years ago

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

Categories

(Core :: DOM: Navigation, defect)

defect

Tracking

()

mozilla1.8alpha1

People

(Reporter: tkkim, Unassigned)

References

(Depends on 1 open bug, )

Details

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".
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.
Component: URL Bar → XP Apps: Autocomplete
Summary: problem w/ address autocomplete → localhost address incorrectly Autocompleted
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...
"127.0.0.1" works for me as well, but this still is a bug?
*** This bug has been marked as a duplicate of 95390 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → UNCONFIRMED
Component: XP Apps: Autocomplete → Embedding: Docshell
QA Contact: claudius → benc
Resolution: DUPLICATE → ---
Summary: localhost address incorrectly Autocompleted → Domain Guessing: Internet Keywords localhost address incorrectly
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Domain Guessing: Internet Keywords localhost address incorrectly → Domain Guessing: Internet Keywords: exclude "localhost" from any "smart browsing features"
Blocks: 178123
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.
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.
Target Milestone: --- → mozilla1.8alpha
*** Bug 233002 has been marked as a duplicate of this bug. ***
Depends on: 232720
This happens to me even when the look up of localhost is fine but the server times out. see bug 320644.
Anyone know where this code lives?
Assignee: hewitt → nobody
OS: Mac OS X → All
Hardware: Macintosh → All
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...)
QA Contact: benc → docshell
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...
Was about to file a duplicate. So obnoxious!
I can't replicate the error anymore - this appears to be fixed in FF 30.0 on Windows 7.
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.
Flags: needinfo?(dteller)
I don't really know who's working on this. Deflecting to ttaubert, for further dispatch.
Flags: needinfo?(dteller) → needinfo?(ttaubert)
Marco, do you know what's happening here?
Flags: needinfo?(ttaubert) → needinfo?(mak77)
(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
Flags: needinfo?(mak77)
(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
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.