1318410 - Global search index remembers address book name even after it is edited or deleted

Status: RESOLVED DUPLICATE of bug 669160

(Thunderbird :: Search, defect)

Description

[Jonathan Kamens]

Probably related to bug 782426, but not quite the same.

1. Create an entry in your address book with the address [e-mail] and the name "Froodle Freedle".

2. Send yourself an email message from [e-mail], with no name in the From line, i.e., with just the email address.

3. Do a global search for "Froodle" and observe that the message you sent yourself matches because the email address [e-mail] has that name associated with it in the address book.

4. Change the address book entry so that its name says "Foo Bar" instead of "Froodle Freedle".

5. Do the search again and observe that it still matches. This is, perhaps, reasonable -- it makes sense for performance purposes for the name to be cached when the message is indexed.

6. Repair the folder, which should cause all of the messages in it to be re-indexed. Then do the search again. Observe that it still matches; this is unreasonable. Re-indexing should no longer index using a name which is no longer actually in the address book.

7. Send yourself another message from the same email address. Do the search again. Observe that it matches the new message. This is unreasonable.

As far as I can tell, the only way to get rid of the name associated with an email address in the global search index is to delete its sqlite database so it reindexes everything. This is unacceptable.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

== context

Gloda Contact names are a best effort type of thing.  When an email address is first seen, an identity and its parent contact are created.  The display name parsed out at that time is set as the contact's name.  If no display name was present, the email address is used verbatim.  At the same time, an addressbook indexer job is queued.

The addressbook indexer logic at https://dxr.mozilla.org/comm-central/source/mailnews/db/gloda/modules/index_ab.js#264 is:
  // update the name
  if (card.displayName && card.displayName != aContact.name)
    aContact.name = card.displayName;

Which is part of the problem here.  I believe the original rationale was that if the user isn't assigning a preferred name to the contact, then the originally scraped display name is probably best.  This code might pre-date the "star an email address to quickly create a contact" which automatically extracts-and-fills in the display name logic.  With that in place, it makes sense to treat an entry displayName as intent.

The second factor is that although a card indexing job is triggered when addressbook changes occur (https://dxr.mozilla.org/comm-central/source/mailnews/db/gloda/modules/index_ab.js#117), no job is scheduled on removal (https://dxr.mozilla.org/comm-central/source/mailnews/db/gloda/modules/index_ab.js#99).  This made sense in context because the indexing really only exists to scrape out explicitly set names and "freetags" (tagging support that never got meaningfully surfaced in the UI).

An overarching issue to be aware of is that the gloda DB representation is fully normalized but does not have reference counts on identity/contact usage.  The identity record and its owning contact can't be safely deleted without ensuring that all message/conversation/whatever references to them are gone.

The best thing that can be done is to reset the state of the contact back so it is as if the addressbook card had never existed.  The simplest action would be to reset the name to the email address of the first identity in question.  A more thorough approach would be to look up an email where the identity/contact is involved and scrape the display name back out from there.

== fixing

There's a few options.  The simplest might be to:
- Change the addressbook listener to queue a job that will cause the card to be re-indexed.  Since the indexer assumes the card exists, it might make sense to create a synthetic record that looks enough like an AB card to not blow everything up and also have a flag that indicates it's a deletion.
- Change the card indexer to treat an empty displayName as a request to purge the existing displayName and replace it with the email address.

The existing addressbook tests at https://dxr.mozilla.org/comm-central/source/mailnews/db/gloda/test/unit/test_index_addressbook.js can be built on.  test_remove_card_cache_indication could be renamed and made to check that the display name gets reset to the email address.

Comment 2

[Wayne Mery (:wsmwk)]

Thanks Andrew for those great comments.  I'll tranfer them to the earlier bug report