1130235 - 31.4 update breaks address lookup frequency ordering

Status: RESOLVED DUPLICATE of bug 1134986

(Thunderbird :: Message Compose Window, defect)

Description

[[:jberkus] Josh Berkus]

I just applied the 31.4 update to my copy of Thunderbird (it's the current update via Ubuntu).  Suddenly, there's no longer any frequency-of-use prioritization on addresses from my address book; the listing of addresses seems to be randomly, or even historically, ordered.

This is a regression from 30.X

1. Open a mail compose window
2. Start typing an name into the To: bar
3. Matching addresses are listed according to some arcane order* 

What should happen:

3. Most frequently used matching addresses should be listed first

What happened to TB?  It seems like the update completely blew away the use frequency stats.

Comment 1

[[:jberkus] Josh Berkus]

* I really can't figure out what order it is using.  It's listing addresses which start with the string I typed before addresses which just contain that string, but beyond that it seems very random.

Comment 2

[Magnus Melin [:mkmelin]]

(In reply to [:jberkus] Josh Berkus from comment #1)
> * I really can't figure out what order it is using.  It's listing addresses
> which start with the string I typed before addresses which just contain that
> string, but beyond that it seems very random.

It's addresses that start with what you type, and those sorted by popularity index ("frequency"). See bug 970456. So, as long as you type in something "not found just inside a word", it's sorted by frequency.

Comment 3

[[:jberkus] Josh Berkus]

Magnus,

Reopening this because what I'm saying that the fix in bug 970456 did not work.  If you'd rather I reopen that bug instead, then let me know.

Let me give you an example to explain what's going on.

I have 6 addresses in my address book called "[e-mail]".

The address "[e-mail]" and "[e-mail]" get used both very frequently, and very recently.

The addresses "[e-mail]" and "[e-mail]" were only used once, ever, each, and that years ago.  The address "[e-mail]" got added to my address book after a typo, and as such was used only once.  "[e-mail]" I've emailed a few times, but not very frequently.

The addresses "[e-mail]" and "Robert Treat" are use with moderate frequency, but not nearly as often as [e-mail] or [e-mail].

Yet when I type in the string "trea", here's the first entries:

1. [e-mail]
2. [e-mail]
3. [e-mail]
4. [e-mail]
5. [e-mail]
6. [e-mail]
7. Robert Treat
8. [e-mail]

As you can see, in 31.4, the direct matching addresses are being sorted into a kind of "reverse frequency order" where the least frequently used addresses are sorted first instead of last.  This did not happen before 31.4.

Comment 4

[Magnus Melin [:mkmelin]]

Can you list those with display names? It's not just the address, but the display name too that affects sorting.

Comment 5

[[:jberkus] Josh Berkus]

Those *are* the display names; they're stored in the address book as naked email addresses.  The only thing I redacted for privacy was Robert Treat's email address.

Comment 6

[Magnus Melin [:mkmelin]]

In that case I don't know. Maybe the popularity index is damaged somehow, but it's hard to check.

Comment 7

[[:jberkus] Josh Berkus]

Well, the damage happened as part of the update then.  Selectivity was working almost perfectly (from my perspective) before the 31.4 update, and this started happening on the first use afterwards.  If it were up to me, I'd revert the 31.4 changes to address selection until we know what's wrong.

Is it possible that it's behaving oddly with addresses that don't have separate display names?  Mind you, I find the "reverse popularity" sort suspicious, maybe you're missing a DESC?

Comment 8

[[:jberkus] Josh Berkus]

BTW, I've tested this with other "begins with" search strings.  It really seems as if there is *no* frequency ordering for the first part of the results, that is the ones which match the "begins with" criteria.  For example, for the string "marc", I got a set of matching results where frequency was essentially random, rather than reversed like the "treas" example above.

Comment 9

[Magnus Melin [:mkmelin]]

Making bug 1134986 the tracker for these.