User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.6) Gecko/20100101 Firefox/10.0.6 Build ID: 20120713125334 Steps to reproduce: Previously I had visited an internal web server, named proto, and downloaded a JPG with spaces in the name, My Homedir.jpg. I then began typing the same URL in the URL field, and was provided the location from history. I press "Down" to highlight, and then "Enter" to select. Actual results: The page presented was a google search: https://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=proto%2FMy+Homedir.jpg Which is what my keyword.URL config setting is set to. Expected results: If I select a page from my history, even if there is a literal space character, the browser shouldn't do a keyword search, it should go right to the page from history.

This used to work when all URL's in history would have been saved with the http or https prefixes.

michael.j.tosh@lmco.com, can you please try to reproduce this issue with a clean profile? http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Confirmed. 1) execute firefox.exe -p 2) create new profile (I used "test") 3) highlight new profile and click start firefox 4) visit a URL with a space in the file name (I used http://prototype/help/Use Help.html) 5) go to a different website (I used http://google.com) 6) begin typing the URL in step 4 in the address bar. When prompted with the address from history, press down to highlight and enter go The URL that is then brought up is: http://www.google.com/search?q=prototype%2Fhelp%2FUse+Help.html&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a As a workaround, if I set "browser.urlbar.trimURLs" to false, it works correctly, bringing me back to the page from history.

This behavior seems to be by design, so I will mark this bug as an enhancement request.

(In reply to Ioana Budnar [QA] from comment #4) > This behavior seems to be by design, so I will mark this bug as an > enhancement request. I disagree. I see this as a regression introduced by the feature to hide the "http" from a URL. If you disable that new feature, this bug goes away. Either way, it doesn't behave the same way with the feature on as off.