User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20100101 Firefox/12.0 Build ID: 20120420145725 Steps to reproduce: connect to a web application I am developing in a url like thus: cotos:1900/Application/page Actual results: The page timeout since completing the requiest required the server to engage in a lenghty process. After the timeout the URL became: www.cotos.com:1900/Application/page Expected results: It should not try to guess the name, since now I cannot just wait a while and click reload, I have to remove the www. and the .com to reload. The guessing for when the server is not found. If it times out, it was found, and chances are that adding www. and .com is not what you want. This policy only makes sense as is under the very unlikely scenario that you guessing that a timeout is very unlike your web server, and thus, the name must be wrong and you must be contacting a different server. Thanks.

A connection reset is more likely

It is not really a duplicate. The previous bug refers to localhost, I'm connecting to another machine in my network. In any case, a connection reset (thanks for pointing that out) should never be interpreted as having the hostname wrong. This still happens on Firefox 13. I'm putting it back as unconfirmed, since it is still not resolved in the latest version. Thanks (In reply to Matthias Versen (Matti) from comment #1) > A connection reset is more likely > > *** This bug has been marked as a duplicate of bug 320644 ***

localhost is just a hostname as any other hostname. I don't understand your "resolved" comment. I don't say that this bug doesn't exists in the recent version and bug 320644 is still open.

Oh, my mistake! I misunderstood the Status. This bug is resolved, the duplicate isn't. Sorry, first bug report. Best

btw: You can disable this feature as workaround. about:config -> browser.fixup.alternate.enabled to false keyword search: keyword.enabled to false