543114 - Read-only/Non-local address books (eg LDAP, Mac AB) should be able to participate in frequency/popularity for address book autocomplete

Status: NEW

(MailNews Core :: Address Book, defect)

Description

[Mark Banner (:standard8)]

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.

Comment 1

[Richard Mlynarik]

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.

Comment 2

[Richard Mlynarik]

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!

Comment 4

[Wayne Mery (:wsmwk)]

xref Bug 457296 - Implement separate whitelist for addresses/domains allowed to load remote images for email

It has a patch in progress.

Comment 5

[Sven Giermann]

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.

Comment 6

[Wayne Mery (:wsmwk)]

contrast with 183554, where user suggests alphabetical order.
But, that bug also has no comments, cc, duplicates, nor votes