User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729) Build Identifier: 3.0.4 I know this bug was fixed & the auto complete is much better, but I'm having a problem when it comes to the letter "S". The most frequently used address is Spam control, yet TB constantly brings up my sister's e-mail address instead. Yes I do e-mail her, but not nearly as often as I use Spam control which is at least 1-3 times per day. I waited a while after upgrading to TB 3.0, but still several builds later still having that problem & it was NEVER a problem in 2.0 & it isn't a problem that I've noticed with any other letter, just "S". Thanks Michelle Reproducible: Always Steps to Reproduce: 1. Both when creating a new e-mail & forwarding an e-mail I press "S" & it brings up my sister's e-mail address instead of the one I use most often which is Spam Control. 2. I then have to use my mouse to scroll to the 2nd entry in my list which is Spam Control. 3. Expected Results: Will bring up the Spam Control which is the most used e-mail addy in my address book.

i can confirm, seeing this with 3.1b2, and not just with the letter S. It's better now that it used to be, but still not what one would expect. My profile is new from 3.0, not migrated from 2.0. Have not tried wiping my profile for recent builds.

I see this in 11.0.1 running under Ubuntu 10.4. In my case the addresses get populated via an LDAP server. This is an important feature since the organization I am affiliated with is quite large.

Chris, Michelle, do you still see this problem? In reply to andrew from comment #2) > I see this in 11.0.1 running under Ubuntu 10.4. In my case the addresses > get populated via an LDAP server. This is an important feature since the > organization I am affiliated with is quite large. andrew, please file a new bug for the ldap issue

Yes, my autocomplete still seems to ignore frequency of use and just present things in the same order all the time. I'm on a Mac so my entries come from the OSX Address Book and TB local storage (I have the option checked to 'auto add outgoing address'. I had thought that this issue was related to using the OS X Address Book - TB couldn't store the frequency stats on the external addr book? I haven't tried a fresh profile in a while, though.

Hi all, I am using Thunderbird 17.0.7 on Ubuntu 13.04, and have the same problem. I started with a clean install (on Ubuntu 12.10, forgot the Thunderbird version) just a few months ago. The problem has always been there. I thought that it will improve with usage, but that has not been the case: the autocomplete suggestions are alphabetically sorted.

autocomplete's algorithm is not to give the most commonly used address based on a single letter. I'd continue but Thomas can probably describe the process better than me and assess whether there is a valid bug here, since he is mucking diligently in this area recently.

I did not say single letter. The most used/reasoned order was one of the most helpful features and now it is gone. It feels alphabetic now. Also it would be of very great help if the auto suggest would not only take name starts. Example is berger (Rosenberger, Spielberger etc.) I often remember just parts of the names and it would be fantstic to get auto suggest also e.g. for the company name xyz@basf.com > show all from basf.com. Appreciate your help! Michael

(In reply to malvers from comment #7) > I did not say single letter. The most used/reasoned order was one of the > most helpful features and now it is gone. It feels alphabetic now. With all respect, but feelings don't help much for correct evaluations. We need reproducable steps and verified results, based on an understanding of the current algorithm. (In reply to Wayne Mery (:wsmwk) from comment #6) > autocomplete's algorithm is not to give the most commonly used address based > on a single letter. I'd continue but Thomas can probably describe the > process better than me and assess whether there is a valid bug here, since > he is mucking diligently in this area recently. Thanks, but my understanding comes mostly from UX and conclusions about code from there (occasionally going into code layers), I'm less firm going the other direction. So don't take my word for this, but this is my current (somewhat vague) understanding of the autocomplete algorithm concerning most frequently used addresses: * We do NOT have a "frecency" algorithm like FF, so actually it won't change anything even if you've recently pulled out the same address from autocomplete results for single letter like "s" many times * We do have a rather simplistic implementation of "popularity index", which I believe works like this: - Each time you actually send out a message to a given address, the popularity index of that card is increased by 1. I don't know any details of this, e.g. if replies also count or not. - When autocompleting, addresses with the highest popularity index will appear first in the results list (so again: *recent* frequency aka frecency does not matter at all) - Popularity index is never reduced, so when you sent 1000 mails to foo@bar.com 20 years ago, it will still stick at the top of your autocompletion lists unless the total sent count (popularity index) for another address becomes higher Depending on the current algorithm (the details of which I really don't know), it might be very possible that what some of you are seeing actually works "correctly" per current design. Say if replies don't count for popularity index, perhaps you composed 10 *new* msgs to your less favourite address, but 100 *replies* and only 5 *new* messages to your favourite address. That might bring your less favourite address to the top, based on higher count for *new* compositions. Wild speculation only, I'm not saying this is what happens. Note that there were some bugs around popularity index in transition from TB2 to TB3, so that might have spoiled the experience even though those bugs were fixed at the time (which also makes me believe that it currently works "correctly" per current design, which is obviously not ideal as it's not based on "frecency"). We should try to understand & verify the current algorithm from code: http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#308 (In reply to malvers from comment #7) > Also it > would be of very great help if the auto suggest would not only take name > starts. Example is berger (Rosenberger, Spielberger etc.) I often remember > just parts of the names and it would be fantstic to get auto suggest also > e.g. for the company name xyz@basf.com > show all from basf.com. Good news: There's a patch pending in bug 529584 which does exactly what you want. Unfortunately, it looks as if it failed to match the deadline due to some technicalities, so we might have to wait another year to see this on release channel. > Appreciate your help! Most welcome.

Also note that *nicknames* should take highest precedence when there's a full match, but that's also broken (bug 325458). But you can use the following workaround to mimick the expected behaviour for both nicknames and frecency: * add a unique nickname to each of your favourite cards, a string that is not found as a substring in any other search-relevant fields of any other card, e.g. ":joe" or "#joe" * type the nickname into recipient area -> autocomplete will return only that match if it's really unique

As for this bug, I don't expect the current design is broken, so it's probably wfm. But I can't prove either way. What we really need is a new RFE to implement "frecency" for autocomplete algorithm, along Bryan's bug 325458 comment 12 (ignore the nickname part of that comment which is flawed).

Unfortunately I can't add a screen shot here. What I'm trying to show is that the search box in the upper right corner has (!) a much better filter/auto complete! By typing "wein" I get all emails containing "wein" like weinberg, weinbach, weinboela, weinhandel .... perfect! This paired with frequency would make me a happy man :)

(In reply to malvers from comment #11) > Unfortunately I can't add a screen shot here. What I'm trying to show is > that the search box in the upper right corner has (!) a much better > filter/auto complete! By typing "wein" I get all emails containing "wein" > like weinberg, weinbach, weinboela, weinhandel .... perfect! This paired > with frequency would make me a happy man :) Good point, malvers, thanks, I hadn't consciously realized that we also have "contains" search for names and addresses in Global Search box (which I rarely use because quick filter bar covers most of my use cases). The "contains" filter that you want is also already realized in Contacts Side bar (F9 in composition), or in Address book. As I said, there's a patch which is going to change autocomplete to use the "contains" logic for all searchable fields as you request, in bug 529584, but you'll need some patience until this lands on release channel. Furthermore, we have another bug linked on bug 529584 which seeks to introduce google style searching with multiple search words used as split string instead of single combined string, which again will make autocomplete by magnitudes more useful.

Hi Michelle, there's an existing bug which covers your scenario of comment 0 (where you expect the same letter "s" to always return "spamcontrol" contact): Bug 382415 - Popularity index of recipient autocomplete doesn't honor timeline (implement frecency algorithm for searching email contacts: weigh how frequently AND recently-used contacts are) Unfortunately, so far there's nobody who has volunteered to fix that. In the meantime, you can use this workaround: Edit your "spamcontrol" contact, and define a nickname in nickname field. Nickname must be unique it should not occur anywhere in your contacts, not even in the middle of words contained in other contacts. So you should set something like "#s" or "sss" as a nickname for "spamcontrol" to ensure that it's the only match when you search for "#s". That should do the trick. Otherwise, there's nothing we can do here afasics (perhaps some things in comments that need to be filed as separate bugs), so I'll mark this as a duplicate of bug 382415. Take care and have a nice week.

Resolved per comment 13.