Aceman, Suyash, can you look into this? (See starting points at the bottom of this comment)

STR are found in comment 45, please ignore comment 0 which has a wider scope not applicable for what we want here.

This bug should be fixed *as a matter of urgency* and landed into TB ESR31, because it renders the nickname feature practically useless without insider knowledge and is now more exposed after the landing of autocomplete twin bugs, bug 529584 and bug 558931.

Although some of the adverse user comments on those bugs are just inconsiderate noise and nonsense (even suggesting we should not search email addresses for recipient autocompletion!), for a certain subset of users there's a trend of complaining that it's now harder to find their favourite addresses with very short searchwords of just one or two characters, for which case they'll see more results not returned before, due to new contains algorithm (*foo*). It all depends on search patterns and AB data structure, but I suspect such users are typically older/longterm private users with small address books. In such user's perception (as evidenced on comments), the old beginsWith algorithm, combined with popularityIndex plain counter, was effectively acting as a shortcut system to their favourite recipients, where typing "Ang" *appeared* to reliably return their favorite contact, "Angus Miller". Of course that has never been true and would fail also in TB 24 even for simple scenarios where user might also have frequent conversation with "Angus Johnson", "Angelina", and "Angelo". But in the combination of narrow beginsWith algorithm and popularity Index, that problem was often hidden for small ABs in private use.

So what such users really want is a stable 1:1 shortcut relationship between their short searchwords ("Ang") and their favourite contact associated with that ("Angus Miller"). That's where we fail miserably because of this bug: Traditional nicknames like "Tom" will largely fail because the contact where Nickname=="Tom" will not be reliably toplisted in autocomplete results, so you end up with "Tony Tomson" toplisted instead if he has a higher popularityIndex.

The other bad problem now more exposed and hence urgently in need of fixing in this context (but much harder than this here), is Bug 382415 (replace popularityIndex with frecency algorithm for autocomplete based on user inputs and picked results), for which a temporary simpler improvement might be something along Bug 1058583 (aging algorithm for popularityIndex).

Aceman, Suyash, this bug here should be relatively easy to fix; starting points in code and outline of potential fix found in comment 50 and comment 51. 

(In reply to Thomas D. from comment #54)
> Aceman, I think this shouldn't be too hard and will be very similar and in
> same code area as your sophisticated patch in Bug 984875, attachment 8428850
> [©] [details] [diff] [review]. My comment 50 and comment 51 also provide a
> starting point how this could be done. Perhaps the combination of your
> insight and my starting points might enable you to come up with a draft
> patch here?

(In reply to Thomas D. from comment #55)
> Oh, and somewhat contrary to comment 0, my understanding of this bug is that
> most importantly, we want to toplist autocomplete results where
> nickname==searchstring (full string match). Haven't thought about partial
> nickname matches much, but strongly suspect we shouldn't undermine
> popularity more than necessary, so just toplisting full string matches would
> suffice for this bug (ignore other sorting suggestions found in comment 0).