736737 - Autocomplete URL in locator bar not functioning properly

Status: RESOLVED INVALID

(Camino Graveyard :: General, defect)

Description

[barrettjunkmail]

User Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.2.28) Gecko/20120308 Camino/2.1.2 (like Firefox/3.6.28)
Build ID: 20120308211433

Steps to reproduce:

Type a URL in locator bar in Camino v2.1.2 for Mac OS X


Actual results:

Autocomplete comes up with results not based on the text you type, but pulls up unrelated results, and also only brings up 10 results rather than all of the matching results


Expected results:

Autocomplete should function as it did before in 2.0.9, where when you type text of a URL, matches should be based on extending the text you type, and ALL matching results should be shown, not merely 10.

Comment 1

[Chris Lawson (gone)]

Can you give *specific* STR, including what you're typing, what you would expect it to match, and what it's matching instead?

Comment 2

[barrettjunkmail]

(In reply to Chris Lawson from comment #1)
> Can you give *specific* STR, including what you're typing, what you would
> expect it to match, and what it's matching instead?

Example of screenshot here: http://img843.imageshack.us/img843/2456/screenshot20120317at125.png

... of the four results that are coming up, only the first one should be, based on what I typed in the locator bar.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Those look like correct results for autocomplete.  Autocomplete was completely rewritten and made significantly more powerful for 2.1.

If you don't want autocomplete to suggest matches based on page titles, you can set a hidden preference to turn it off: http://caminobrowser.org/documentation/hiddenprefs/#AutocompleteOnlyURLs

Resolving INVALID because everything appears to be working as designed.

Comment 4

[barrettjunkmail]

No, setting the autocomplete setting to FALSE does not fix this.  I had already tried that (and restarted Camino) when I sent the screenshot earlier in this bug report.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

All of the results in the screenshot have one or more 'words' in the URL that start with "hotm", so they're being suggested as expected.

Comment 6

[Stuart Morgan]

(In reply to Smokey Ardisson (not following bugs - do not email) from comment #5)
> All of the results in the screenshot have one or more 'words' in the URL

Specifically, in the domain (which is the only place we match for URLs).

Comment 7

[barrettjunkmail]

Right, but what it should be doing (based on behavior in previous versions) is to follow the starting "stem" string of the text being entered.  If this isn't a bug but rather a "feature", then I would strongly recommend making this option available as a hidden pref.  Also, there should be a pref to control number of results rather than limiting to 10, because inevitably you might want to scroll through a large number of results all of which have the same starting string.

Comment 8

[Chris Lawson (gone)]

(In reply to barrettjunkmail from comment #7)
> Right, but what it should be doing (based on behavior in previous versions)
> is to follow the starting "stem" string of the text being entered.

Can you explain what it is that this means, exactly, and how it would apply to the situation you've got here?

Comment 9

[Chris Lawson (gone)]

And while you're at it, explain why presenting only one result in this scenario is more helpful to the user than presenting all four results. As I understand it, your "desired" result is still the first one, so this conscious behavioural change hasn't actually made things worse.

Comment 10

[Stuart Morgan]

This change was intentional; it's not a bug. We have no plan to make it available as a hidden pref. Please don't re-open bugs just because you personally disagree with the decisions we've made.