Open Bug 543114 Opened 14 years ago Updated 1 year ago
Read-only/Non-local address books (eg LDAP, Mac AB) should be able to participate in frequency/popularity for address book autocomplete
Currently only local address books can store the PopularityIndex value that is used in the autocomplete mechanism. Other address books can't because either they are read-only, or they don't have a place to store that bit of data. This is expected to be a long-term fix as the two most likely solutions would be: - Use information from the global database. - Provide some sort of wrapper which encompasses all address books and allows for saving of fields like this.
From a user perspective I DO NOT WANT TO EVER HAVE TO USE a Thunderbird-specific address book. I already have an address book. I use it all the time. Other applications also use it. No other application uses Thunderbird-specific address books. So any "fix" to address completion sort-order that does not address this issue is simply worthless to me. https://wiki.mozilla.org/User:Standard8/Thunderbird_Autocomplete is, frankly, useless if it doesn't recognize this basic user expectation. The mail program needs to work with the user's data, not force the user to change. I suggest that the second solution, "Provide some sort of wrapper which encompasses all address books and allows for saving of fields like this" is the correct one. It even _sounds_ like an easy solution -- certainly it seems easier than wedging this information into address book tables, especially as the information stored is COMPLETELY INDEPENDENT of any particular address book. What Thunderbird is counting, or ought to be counting, is just the number of times a particular string -- NOT an address book entry, or a particular email address of a particular address book entry of a particular address book -- has been typed in or selected by the user as an email recipient. That is independent of address books, and should just be stored globally (well, per user profile) outside of ALL address books. When I type "foo" into a mail composition window, I, as a user expect the system to find all matching "foo"s from all possible address books, and the to sort by use frequency INDEPENDENTLY of the source of the particular entry that matched the string "foo". In short, it is a BUG that recipient use frequency is stored in address books, because from a user interaction perspective I am completing a free-form string and I'm always interested in the most-used completion of that string, and I don't perceive myself as navigating a hierarchy of address books and a hierarchy or addresses associated with address book entries.
Comments copied for reference from "resolved fix" (ie "define the bug out of existence by giving it a different number which doesn't block a release") Bug 497722 : Here's what I, AS A USER, want to see and expect to see [...]: (A) When auto-completing addresses, the MOST-USED matching completion should be sorted to the top of the list, and less-used completions should appear lower. This is INDEPENDENT of whether the email address is designated as "primary" for a particular address book entry. (B) The "most-used" order should be weighted most strongly by addresses to which I have sent mail. If we have to start form scratch and you can't recover that information from TB2 or buggy TB3 data, fine. Just start doing the right thing AS SOON AS POSSIBLE. (..B2) In an ideal world, addresses I type in manually or select manually from an auto-completion list would be weighted more strongly than addresses which are filled in automatically by "reply" or "reply to", but this is a small enhancement request compared to fixing the horribly broken main bug. (C) When multiple completions with the same most-used count match a partial input string, give preference to addresses that are designated as "primary" address book entries. Note that this is a SECONDARY SORT ORDER -- the most-used criterion should always win out over a primary designation. (..C2) enhancement request, but just since I'm listing how I want things to work: addresses designated as "other" (versus "work", "home", etc) in my MacOS address book should have lowest priority. This is like being designated the opposite of primary. Again, it only affects a secondary sort order. (My address book has many alternate and or former email addresses which I keep for various database and historical reasons. No, I am not going to manually delete them; so it would be nice if stuff that used by address book, like Thunderbird, were smart enough to value some email addresses more than others.) (D) I only want to use one address book on the platform I use, namely the MacOS address book. Any "fix" to this bug or class of bugs that requires me to copy information into some Thunderbird-specific address book, or to maintain multiple parallel address books, IS NOT A FIX. (I don't care where Thunderbird stores its most-frequently-used address count; that doesn't have to be in my one system-wide address book since it's likely to be application-specific data. What I don't want is any *user-visible* evidence of this, in particular in the form of a user-visible Thunderbird-specific address book.) [...] Thanks. I'm really trying to be helpful here, and I don't think my expectation as a USER are unrealistic or extremely idiosyncratic. Getting email addressing to work right (ie more of less "invisibly", ie so correlated to reasonable user expectations that the user never needs to think about it) is one of the most important parts of the mail reader UI in my opinion. Look at the work that has gone into making the Firefox address bar as useful and convenient and as "do the right thing nearly every time" as it is today -- that's a big selling point for Firefox adoption, and the equivalent will make TB more attractive to new users (and frustrated existing users after the TB3.0 downgrade-upgrade.) [...] My implementation guess is that fixing the other issues might also fix Bug 543114 "for free", since my guess or naive suggestion about the correct implementation solution for this whole class of bugs is to store most-used email address completions as strings in a separate, very simple database, that simply maps string->count, and to do this independent of any particular user-visible address book. Another nice side effect is that this should end up being completely platform-independent. Hooray!
Summary: Read-only/Non-local address books should be able to participate in frequency/popularity for address book autocomplete → Read-only/Non-local address books (eg LDAP, Mac AB) should be able to participate in frequency/popularity for address book autocomplete
Target Milestone: Future → ---
xref Bug 457296 - Implement separate whitelist for addresses/domains allowed to load remote images for email It has a patch in progress.
I just stumbled across this issue... Thinking about it, I found reasonable workaround which could be implemented fairly easy: a) implement a global option to set the sort preference of addresses without PopularityIndex: Top or Bottom (which is current default) b) the same, but address book specific - gives ability to sort some read-only books Top, others Bottom c) at least (or in addition) have that option next to the LDAP search setting for autocompletion (global and/or account based) What do you think? At least a and c should be very easy to implement - although it would be no real fix for the problem mentioned, it would help maybe many people around. I'm talking about global read-only LDAP books, centrally managed - they mostly contain verified and valid addresses, while some local books (i.e. auto collected) might be out of date already.
contrast with 183554, where user suggests alphabetical order. But, that bug also has no comments, cc, duplicates, nor votes
See Also: → 183554
You need to log in before you can comment on or make changes to this bug.