The address bar has a feature where you start typing, and it auto-fills the text field with the full domain name of the website. However, when it fills in a website this way, it does not include the port number for websites that aren't on port 80. This only applies to the suggestion that is auto-filled into the text box. The normal suggestions that drop down work perfectly. Steps to reproduce the problem: 1) Frequently visit a website which does not run on port 80. For example, http://bootgod.dyndns.org:7777/ 2) Try to visit that website by entering the beginning of the domain in the address bar, like "boot" 3) Rest of the domain name is filled in, giving "bootgod.dyndns.org/", but that is the incorrect URL since it is missing the port number.

It's quite a bit of added complication to support ports, though we may evaluate how bad it is.

The simplest solution may be to completely change the storage, if we don't ever plan to disable ".typed", we may stop storing all hosts, and instead store tuples like "searchable,returnvalue". Though this may disallow other performance improvements like being able to get hosts sorted by frecency (about:permission and such). To be evaluated.

Marking this as a minor bug, since it's autocompleting an address I've never entered, and one that doesn't even respond.

(In reply to Roman from comment #4) > Marking this as a minor bug, since it's autocompleting an address I've never > entered, and one that doesn't even respond. I'm not sure it's justifiable to call it minor just because you don't use URLs with explicit port numbers. For anyone working with IP-based hostnames or local servers, this is essential. Even popular consumer apps such as Airdroid for Android requires URLs with port numbers such as 8080. Can't you map ports to hosts when storing all hosts? Because the hostname alone, without a port, is pretty useless if the host isn't running a site on port 80.

P.S. I filed a duplicate at https://bugzilla.mozilla.org/show_bug.cgi?id=853898

Agreed. > Can't you map ports to hosts when storing all hosts? Because the hostname > alone, without a port, is pretty useless if the host isn't running a site on > port 80. If you're asking me then I don't know; I'm just a Firefox user with the most basic level of extra privileges on Bugzilla. I am not a Firefox developer.

This is a real problem for developers as well. I'm always trying to access rails apps running on my machine and accidentally going to myapp.local instead of myapp.local:3000 - the same goes for control panels on linux servers and some webmail. On a more general point I really don't understand why Firefox doesn't just go to the first awesome bar result if you press enter. It feels like you spent ages building the prediction power of the awesome bar (which really is awesome) and then threw it all away when I press enter to go to the root of a domain which I never visit normally.

<blockquote> It feels like you spent ages building the prediction power of the awesome bar ... and then threw it all away when I press enter to go to the root of a domain which I never visit normally.</blockquote> This sums it up quite well. What is the point of auto-completion if it goes somewhere else? That was the crux of my bug which just got duped here. This comment expresses it better than I did. Port number is NOT an optional extra. A corollary of this is that if I have a locally named server like mylocalhost reponding on 8080 , auto-complete, having failed to find it on port 80, starts adding .com to the end and fails saying it cant locate http://mylocalhost.com when I never asked it to. This has been designed by someone who does not seem aware that we servers are not necessarily responding on port 80 and has not even considered the existence of port number in the protocol. Needs fixing.

As a developer, this was a significant constant papercut that I stopped using Firefox as my development browser. When trying to load "localhost:3000" in Safari and Chrome, the flow is New Tab -> "l" -> pause while "localhost:3000" is autofilled -> Enter. In Firefox it's New Tab -> "l" -> pause while "localhost/" is autofilled -> right arrow since the whole thing is highlighted -> backspace to delete the "/" -> ":3000" -> Enter. For something I do a hundred times a day it was frustrating enough to stop using Firefox.

(In reply to gabe from comment #16) > In Firefox it's New Tab -> > "l" -> pause while "localhost/" is autofilled -> right arrow since the whole > thing is highlighted -> backspace to delete the "/" -> ":3000" -> Enter. I agree, it's annoying if you hit it multiple times a day. Fwiw you could try using a bookmark or a keyword to workaround the problem. It's also very likely the entry you are looking for may be the second one, so just down+Enter would do. To properly fix this I feel like we'd also need a better way to pick the most relevant result in bug 1239708. It may also be interesting to allow somehow to quickly replace/input a port, for example if we fill "loc[alhost:3000]" pressing ":" should probably change text to "localhost:[3000]" to allow quickly changing the port. This could also be a low hanging fruit improvement to make this bug far less annoying, indeed we could on "l[ocalhost/]" and a ":" keypress, directly move to "localhost:|" (equivalent to RIGHT+BACKSPACE+:). I'm adding this to our team tracking, but I can't predict when we may find resources to work on it. The low hanging fruit improvement could probably be coded in urlbarbindings.xml, where we intercept input. It would also need a specific mochitest-browser test. And should happen in a new bug blocking this one. Since you're a developer, maybe you may be interested in giving it a try? I'll be glad to help mentoring such a change.

I filed bug 1345133 to cover my suggestion, in case anyone wants to try fixing it.

(In reply to markg from comment #22) > Mostly enjoying the new Firefox experience after a break of nearly 10 years > where my goto browser was Chrome. > But this bug is so irritating that it's really going to stop me and I guess > a lot of other people from using Firefox. > > Seems incredible that this bug has been open for 5 years and either isn't a > priority or is somehow too difficult to fix. Same goes for me.

We are actively working on the dependencies.

I'd like to briefly mention a small security vulnerability here. A MITM who knows this behavior can look for non-port-80 SSL connections, such as Drytek, Watchguard and other well-known firewall devices. Then they can listen and respond on port 80 *without an SSL cert* ... which is normal behavior for port 80 and won't cause any alarms in Firefox. At that point they attacker can wait for connections from Firefox users and phish firewall passwords.

new autofill supports this, and I just tried this in Nightly. Fixed by dependencies.