Closed Bug 424509 Opened 15 years ago Closed 14 years ago

Location bar autocomplete favors "http://" over domain name starting with "h"


(Firefox :: Address Bar, defect, P2)




Firefox 3.1a2


(Reporter: moz, Assigned: Mardak)



(Whiteboard: [Fx2-parity])


(2 files, 2 obsolete files)

Linux, 2008032104:
1) Open a new profile with a few bookmarks.
2) Go to
3) Type "h" in the location bar.

Result: Lots of results starting with "http://"
Expected result: Domains starting with "h" (e.g. at the top of the list.

=> Give protocol part of the URL a very low priority in autocompletion.
Blocks: 405745
Flags: blocking-firefox3?
Duplicate of this bug: 424670
The learning algorithm should fix this, mostly, but ignoring the protocol when matching against the URL is probably a good idea when the user has typed only *part* of http:// or https:// -- when they've typed it all, we should definitely match -- as is stuff in the eTLD list.
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-
OS: Linux → All
Priority: -- → P2
Answer me this: Why would a user in their right mind ever try to autocomplete on http://? It will return every web site that user has ever visited that uses HTTP. It should match on the domain name, like if I want to look up a site in my history like It might have limited use in finding NON-http protocols.

I vote for a heuristic to drop the score of hits against the protocol http://. Likewise for TLDs like com, net, etc. More detail in Bug 424670.
FYI: If you go to the location bar right now and press down, it'll do a search with the current url... which likely has http://
Matching against http://, or not, have their pros and cons. If I type just http://, I would expect the top HTTP URLs in my whole history to drop down, in order of decreasing frecency, but not those with file:, https:, about: or chrome: at the start -- and I have quite a number of these four too.

And, Skewer, if you say I'm not of right mind -- I can live with that. :-)
Attached image screenshot of v1
This will be fixed by the patch in bug 424717.
Assignee: nobody → edilee
Depends on: 424717
Hardware: PC → All
Whiteboard: [Fx2-parity][has fix in bug 424717]
Attached patch testcase v1 (obsolete) — Splinter Review
Does this build fix the issue for you?

Bug 424673 - Optimize AwesomeBar for correcting typos or removing terms that caused no results
Bug 422277 - assertions in nsNavHistoryAutocomplete ("not a UTF8 string", etc.)
Bug 422698 - different levels of URL decoding for address bar and autocomplete suggestions
Bug 424717 - Location bar autocomplete should be willing to complete to a URL with a different protocol
Bug 424509 - Location bar autocomplete favors "http://" over domain name starting with "h"
Bug 418257 - Show what part of which tags match for urlbar autocomplete
Bug 424216 - displaying filename/path instead of title for (unvisited?) bookmarks
Bug 392143 - show keywords as url bar autocomplete choices
Bug 249468 - Add all bookmark keywords to location bar autocomplete drop-down list
Bug 395161 - Make it possible to restrict the url bar autocomplete results to bookmarks/history entries and match only url/title/tags
Bug 420437 - Search and emphasize quoted strings with spaces
Bug 423942 - "Clear List" in download manager should be "Clear Current List" during the search
Bug 424557 - Allow AwesomeBar to default search only urls (or history/titles/bookmarks/tags)
Bug 423718 - Use native platform colors for URLs in the location bar autocomplete, make the line between rows lighter
Bug 424213 - URLs without corresponding title are displayed with a blank title (which isn't full-height)
Bug 415190 - Autocomplete results can be incorrectly sized (clipped)
Bug 414326 - Use DownloadUtils for software update downloads
Yes, this fixes the issue from comment #c0. Thank you!
How to search for URLs which -start- with the search term (maybe after "http://" or "http://www.") as in previous versions?
So you can't match on "http://", but you can match on "www." with this build:
it still shows all URLs which contain the string, not only these which start with the string.
Blocks: 424717
No longer depends on: 424717
Blocks: 422698
Depends on: 422277
Whiteboard: [Fx2-parity][has fix in bug 424717] → [Fx2-parity][has patch][need dietrich review][need bug 422277][has more testcases in bug 422698, bug 424717]
Attached patch v1 (obsolete) — Splinter Review
This also fixes bug 422698 and bug 424717 both have their own test cases as well.
Attachment #311618 - Attachment is obsolete: true
Attachment #313760 - Flags: review?(dietrich)
All dependencies are clear, is wanted-firefox3, has 3 separate testcases ready to land with this.
Whiteboard: [Fx2-parity][has patch][need dietrich review][need bug 422277][has more testcases in bug 422698, bug 424717] → [Fx2-parity][has patch][need dietrich review][has more testcases in bug 422698, bug 424717]
I came across the same problem even for the letter 'p', which effectively means 'p' is now my shortcut for a list of my most recently viewed sites, regardless of the domain!
Duplicate of this bug: 439549
Attached patch v1.1Splinter Review
Cleanup the testcase to use the new compact format.
Attachment #313760 - Attachment is obsolete: true
Attachment #331821 - Flags: review?(dietrich)
Attachment #313760 - Flags: review?(dietrich)
Comment on attachment 331821 [details] [diff] [review]

r=me, thanks!
Attachment #331821 - Flags: review?(dietrich) → review+
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [Fx2-parity][has patch][need dietrich review][has more testcases in bug 422698, bug 424717] → [Fx2-parity]
Target Milestone: --- → Firefox 3.1a2
Verified FIXED using:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/2008080702 Minefield/3.1a2pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a2pre) Gecko/20080808020649 Minefield/3.1a2pre

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a2pre) Gecko/20080808031528 Minefield/3.1a2pre
You need to log in before you can comment on or make changes to this bug.