Comment 46 for bug 956618

(In reply to Deven Corzine from comment #43)
> How does such an obvious bug get filed and debated for year (2013), after
> year (2012), after year (2011), after year (2010), after year (2009), after
> year (2008), after year (2007), after year (2006)... but never actually
> fixed?

Deven, thanks for your feedback. I appreciate the frustration, as I've often felt it myself (being an active volunteer TB QA/UX contributor since 2007). However, we need to face the fact that TB has a track record of unresolved bugs for a variety of reasons. Where this bug is just one out of many, and the choice of "important" bugs to start from is pretty vast.

TB is now maintained almost exclusively by volunteers, so getting this bug fixed requires a volunteer who is a) able, b) willing, and c) has the time to actually fix this, and d) an agreement about the exact goal of this bug, the desired UX how it should be fixed. a) and c) are the hard parts, whereas I'd consider d) a non-issue in this case (although looking at the entirety of comment 0, to which comment 12 responds, I suspect misunderstandings about d) also contributed to the long latency of this bug).

> This worked in Thunderbird 2, which means it's a regression bug, not an
> enhancement.

Deven (and others before), thanks for pointing that out. Understanding the nature of a bug and documenting that as precisely as possible in the bug report is crucial.

Indeed, this looks like a bug because it violates the very purpose of the nickname design, which is a 1 on 1 relationship between the (ideally unique) nick and the card, to allow user to retrieve and distinguish that card efficiently and consistently from all other cards. (As a caveat, note that TB is not enforcing uniqueness of nicks!). As has often been said in this bug, users correctly expect from the intrinsic purpose of nickname design, that nicks should have absolute priority in searches, which includes priority over frecency. Frecency is a way of automatically establishing dynamic nicks, but certainly nicks that have been purposefully and explicitly defined by user must take precedence over that (why should I add "wil" as a nick to my uncle's card if I don't want "wil" to find that very card?). Users who want the frecency algorithm to take highest precedence probably wouldn't (and shouldn't) define explicit nicks.

Due to violation of these imo correct, established, and widely-evidenced user expectations, this is a bug in terms of UX error prevention where users can easily inadvertently send the msg to the wrong recipient(s), which is a major violation of their privacy. As such, this bug also undermines UX trust in TB as an application, as repeatedly stated here in line of comment 0 and comment 43:

> You may not think this is important, but anything that causes mail to get sent to
> the wrong user inadvertantly is just about he worst possible problem a mailer can have.

> There has been ample evidence that this seemingly-minor issue
> is a major source of frustration to many users, even to the point of
> abandoning Thunderbird entirely. It may be a little thing, but that doesn't
> mean it doesn't matter.
>
> Instead of debating the best algorithm for years, why not at least add a
> special-case check for an exact match of a unique nickname, before going
> into the current algorithm? That would satisfy the critical use case,
> making most of the frustrated users happy. A special-case should be trivial
> to add, for anyone who knows the code, so why hasn't that much been done
> after nearly 8 years of this ticket being marked as NEW?

See my remarks further up in this comment. Getting bugs fixed in TB is often less trivial than it looks, for a variety of reasons...

FTR: I agree that the obvious solution to this bug (as required by the intrinsic principles of "nicks" design concept) is to list fullstring matches on nicks at the very top of the recipient autocomplete dropdown, so that they take highest precedence (even before frecency if we implement that). Btw FF works the same way for keywords: Keywords (not tags, nor frecency) take absolute highest priority over any other matches. Think of keywords and nicks as an ALIAS for the real thing.