779485 - selecting an intranet url containing spaces in the filename from dropdown history goes to search

Status: RESOLVED DUPLICATE of bug 690307

(Firefox :: Address Bar, defect)

Description

[miketosh]

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.

Comment 1

[miketosh]

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

Comment 2

[Ioana (away)]

[e-mail], 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

Comment 3

[miketosh]

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.

Comment 4

[Ioana (away)]

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

Comment 5

[miketosh]

(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.