This is an edge case of the new URL autocomplete feature (see bug 659437, c0). Steps to reproduce: 1) bookmark a page, e.g. facebook.com, and assign it a keywork, say "fb" 2) visit fbackup.com or any other url with domain name starting with "fb" to add it to your browsing history 3) type "fb" in the urlbar and hit ENTER Expected results: fb is recognized as a keyword, Firefox opens the associated bookmark, facebook.com Actual results: Firefox autocompletes the URL with fbackup.com and gets you there as you hit ENTER. I think that keywords should have priority over URLs, since they are assigned by the user.

In my opinion keywords hold higher priority and in anycase you still can press down arrow and choose desired alternative

I think it will be easier to fix this from the Places autocomplete implementation side, by not returning a result if the search term matches a keyword.

needs a test yet, though, since all the inline ac harness is missing, it should probably just be added in bug 715133. Will check what's the best way on, if work on those tests started or not.

Added a new test harness we can use in bug 715133 and a test using it

Comment on attachment 591152 [details] [diff] [review] patch v1.1 >diff --git a/toolkit/components/places/tests/inline/head_autocomplete.js b/toolkit/components/places/tests/inline/head_autocomplete.js >+function run_test() { >+ try { >+ Services.prefs.clearUserPref("browser.urlbar.autoFill"); >+ } catch(ex) {} >+ try { >+ Services.prefs.clearUserPref("places.history.enabled"); >+ } catch(ex) {} Don't need the try/catches anymore (since bug 487059)

Removed the try/catch https://hg.mozilla.org/integration/mozilla-inbound/rev/ddba51717872