469963 - When there is no exact match for http://foobar, autocomplete should return http://www.foobar before https://www.example.com/something.cgi?id=foobar

Status: NEW

(Firefox :: Address Bar, enhancement, P3)

Description

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081216 SeaMonkey/2.0a3pre - Build ID: 20081216000501

Reproducible: Always (but depends on bookmarks and/or history)

Steps to reproduce: (with my history)
1. Enter http://sea into the location bar and watch the autocomplete widget.

Actual results:
https://bugzilla.mozilla.org/describecomponents.cgi?product=SeaMonkey appears before http://www.seamonkey-project.org/

Expected results:
Opposite of the above: I would (ideally) expect:
1) Exact matches (if any). At the beginning if the typed string includes a URL scheme.
2) Any matches allowing for fixup prefix if enabled (if the typed string includes a URL scheme).
3) Other matches (if any)

Additional info:
- I tried to take a screenshot but giving focus to KSnapshot closes the SeaMonkey autocomplete widget.
- Rationale for expected result #2: I may remember a URL except that I'm not always sure whether a www. prefix is needed. If I type the full URL without www, SeaMonkey will "fix it up" if necessary. Autocomplete ought to do the same for a partial URL.
- Matches in the same category should of course be sorted by frecency. This means that when typing "seamonkey" _without_ the http:// prefix, the above ...?product=SeaMonkey would be expected to appear before seamonkey-project.org if I've been browsing the former more often / more recently than the latter.
- I'm not convinced of the relevance of any matches with only part of what I hand-typed. (This is not incompatible with the bug recently fixed, and rightly, to avoid matching "ht" with the _longer_ "http://" scheme or "tp" with practically anything at all.)

Comment 1

[Robert Kaiser]

The matching algorithm we're using (now) is in toolkit places, so moved there.

And actually, I think you're talking of items with the same frecency here - once you have called up the URL you want only a single time, I'd expect it to be ordered before the other one (unless you're calling that one up more often from the urlbar, when it gets higher weight/frecency).

Still, leaving up to places people what they think on the matching here.

Comment 2

[Tony Mechelynck [:tonymec]]

In reply to comment #1:
In the case considered in comment #0, my triager activity actually makes me browse the various subpages of BMO describecomponents.cgi much more often than the seamonkey-project.org page: in fact, I have one tab set more or less permanently on a describecomponents page, and I switch pages by removing the query part in the URL bar and using a different autocomplete item, or typing a different query if the one I want isn't seen in the autocomplete list.

But it would never have crossed my mind that https://bugzilla.mozilla.org/describecomponents.cgi?product=SeaMonkey would be expected as a valid autocomplete result to http://sea (hand-typed as such, including the http:// scheme). OTOH adding the www. prefix is something that _is_ expected if there is no result without it.

Comment 3

[oismuncher]

Even more important, when the user enters https:// as the prefix, https matches should take precedence over http matches. Otherwise users may inadvertently go through a non-secure page.

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

This should be re-triaged in the Address Bar component

Comment 5

[Mark Banner (:standard8)]

The fact the user has typed a protocol is a signal that we are not currently using. We should consider making use of that.