Open Bug 460737 Opened 16 years ago Updated 2 years ago

Quickfilter ignores searches for friendly display names from address book contacts, as displayed on message header and message list by default (no or incomplete results for From, To, CC, BCC)

Categories

(Thunderbird :: Search, defect, P2)

Tracking

(Not tracked)

People

(Reporter: thomas8, Unassigned)

References

(Blocks 1 open bug, )

Details

(4 keywords, Whiteboard: [enterprise-relevance][needs followup bugs for comment 6 and comment 19][datalossy])

Attachments

(1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3 tb3a3 New message reader converts original from-header (others respectively) from "Originally Sent Display Name <existing_contact@asdf.com>" to "My contact Display Name" using contacts from my address book. My expectation was that if I use Quick Search to look for that known sender using "My contact Display Name", TB should find the mail. However, it doesn't. I think it should: since the sender's email address is clearly associated with its display name in my address book, even though sender decided to use another display name for his mail. Which leads to tricky questions of consistency throughout TB: - in the message list, should display names also be converted to known display names as it is done in the message header pane of message reader? Is it confusing to have a possibly completely different looking sender display name in the list than in the message reader display for the same email address? Even without touching the consistency issue, perhaps you could still allow searching for friendly names that are in my address book but not on the sender's mail, when the email address is the same. Reproducible: Always Steps to Reproduce: 1. original email has from-header "P. Smith <psmith@asdf.com>" (the display name Peter chose for sending) or even just "<psmith@asdf.com>" (no display name chosen by sender) 2. my address book knows "Peter <psmith@asdf.com>" (my contact display name for Peter) 3. looking at message reader's translation of "P. Smith" into "Peter" (yellow-star), I want to search for all emails sent by "Peter" using Quick Search, so I instinctively type in "Peter" (as that's the display name associated with psmith@asdf.com, is it not?) Actual Results: - Message List shows "P. Smith" (or "psmith@asdf.com") as sender - Message Reader shows "Peter" as sender - Quick search for "Peter" yields no results :( Expected Results: 1.) Quick search for a friendly display name that is associated (in my address book) with the sender's email address should yield results, regardless of which display name sender used for sending (or even if he chose not to use a display name at all). 2.) As far as consistency is concerned, maybe sender display in message list should be translated to known display names, as it is done in message reader (not sure about this one). However, where can I then see the original display name as used by sender? (Should be accessible, too!). Consistency and comfort of contact's display aliases vs. accuracy and "true" display of original sender is tricky on this one.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090612 Shredder/3.0b3pre I'm really looking forward to a better Thunderbird, and before going any further, here's a big and appreciative thank you for all the great work that you do in digesting the tons of problems and suggestions that users dish up to you, and for the great effort you put into developing the bird! I'm aware that supporters like me necessarily don't always have that overall viewpoint that you have. On the other hand, multiple views may contribute to a better overall picture and point out some of those details that might get lost when you're into the big picture much of the time... This bug is still present in the current nightly and should be confirmed. Users will find it irritating to see "Peter" (yellow *) as the sender in message reader's display (which shows the friendly name from address book based on a matching email address), while they won't get any results when they quick-search for the sender "Peter" because quick search ignores friendly names. The intended focus of this bug is clearly on the first half of the summary, i. e. no. 1.) of expected results.
Bryan ?
Component: General → Message Reader UI
QA Contact: general → message-reader
Confirming. Quick search shouldn't ignore friendly names, given that with the implementation of bug 462578 (Quick search should have "Subject or contact (From, To, CC or BCC)" option), we are promoting name-centered quick searches even more than before (bug 462578 just added a quick search option to search for "Subject, name or address" which also allows to retrieve all correspondence from/to a specific person /by name/, which is where this bug here becomes more relevant). Completeness of user's quick search results shouldn't depend on what the sender happened to choose (or not) as a display name. Also think of changing display names, e.g. when people marry etc. Underlying email address might still be the same, and unless this bug gets implemented, such scenarios would need two or more searches to retrieve all correspondence by name.
Status: UNCONFIRMED → NEW
Ever confirmed: true
If you're looking for something from "dad" i wouldn't expect it to find the mail by searching for the *name* "dad". Obviously you do though. I doubt it's worth the effort to implement.
(In reply to comment #4) > If you're looking for something from "dad" i wouldn't expect it to find the > mail by searching for the *name* "dad". Obviously you do though. That's the extreme case. I was thinking of more everyday cases where the /sender/ might have chosen anything for the mail's from-header, like "M. Melin <mkmelin+mozilla(at)iki.fi>" or "Magnus <mkmelin+mozilla(at)iki.fi>", or "MM <mkmelin+mozilla(at)iki.fi>" perhaps even just "<mkmelin+mozilla(at)iki.fi>", whereas I as a user have chosen and saved a single instance of "Magnus Melin" as a display name in my address book. Looking at the mail in preview (and that's where I look most of the time), TB (having compared the mail with the addressbook) officially shows/claims the mail was sent by "Magnus Melin (yellow *)" User wants to find all other correspondence from/to Magnus Melin: I don't think it's extraordinary/unexpected in any way that user will try quick search for "Magnus Melin", /as displayed in the message reader/. Due to this bug, depending on which from-header sender used, "Magnus", "Magnus M", or "Magnus Melin" will all return no results. Another Example: Many people are keeping a copy of their sent mail in their inbox, exactly for purpose of having the whole conversation in one place. I used to have "Magnus Melin" as my addressbook's display name, then I changed it to "M. Melin" and finally I have come to appreciate him as just "Magnus M.". Or maybe I once had "Melin, Magnus" as a display name. So of the sent mails in my inbox that are part of my conversation with Magnus, some of them will each have the respective different from-headers. Again, any search for the whole conversation will be hopeless unless friendly names are permitted in quicksearch.
The gloda search which is in current nightlies does what you suggest. Please try out a current nightly, customizing your toolbar to include the "Search In Messages..." labeled search box. Make sure that you have enabled gloda: https://wiki.mozilla.org/Thunderbird:Using_Gloda Note: There is a current limitation which is that changing the name of a contact or adding a new contact does not cause messages by that contact to be re-indexed, and so the search will not catch them on the basis of the contact name.
Component: Message Reader UI → Search
QA Contact: message-reader → search
(In reply to comment #6) > The gloda search which is in current nightlies does what you suggest. Maybe, but how does that help me for quick-filtering, which is what this bug is about (e.g. using "Subject, From, or Recipient filter")? > Note: There is a current limitation which is that changing the name of a > contact or adding a new contact does not cause messages by that contact to be > re-indexed, and so the search will not catch them on the basis of the contact > name. Does this limititation still exist? (I think yes). If yes, could you file a bug for it?
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → 3.0
Blocks: filterbar
No longer blocks: filterbar
I think what you are requesting is well within the capability of an nsIMsgSearchCustomTerm, so I will at least add this as a requested feature to FiltaQuilla, where I experiment with those.
Related Bug 312821 - Thunderbird doesn't use display name for people I know within the thread pane (although I am not sure that bug is a good idea)
Summary: Quick search ignores friendly contact names / inconsistent UI displaying addresses in message list vs. message reader → Quickfilter ignores searches for friendly display names from address book contacts / inconsistent UI displaying addresses in message list vs. message reader
The wanted-thunderbird+ flag should be set for this bug, as it's a considerable and confusing UI bug that significantly affects the possibilities and efficiency of quick-filtering.
mike, rsx11m, do you agree with the following? (I'm not in a position or have time to think on it) If you agree, please nominate via flag (In reply to comment #10) > The wanted-thunderbird+ flag should be set for this bug, as it's a considerable > and confusing UI bug that significantly affects the possibilities and > efficiency of quick-filtering.
Meanwhile TB 3.3a3pre (in my case: build 2011-02-16) respects the display names from the address book when carrying out a Quickfilter search. So obviously Bug 243631 fixed this problem here ?
(In reply to comment #12) > Meanwhile TB 3.3a3pre (in my case: build 2011-02-16) respects the display names > from the address book when carrying out a Quickfilter search. > So obviously Bug 243631 fixed this problem here ? That bug only affected display logic, not the actual filtering operation of the quick filter. (I just confirmed with a quick local test.) The display logic does have a side-effect where it caches display names on the message headers. However, we can't use that information because we can't rely on it being there. (Well, we could do a hideous hack where we fake displaying all the messages in the folder, but that has serious performance issues in terms of execution time and memory/GC burden.) The non-gloda search subsystem needs to be extended to support an explicit predicate for this use-case. A lot of that display logic could be reused...
Re comment 13: You are right. I am sorry. I made a mistake: I searched for words (like "office") that were coincidentally part of some display names (e. g. "John (Office)" ) as well as part of some of their mail bodies (e. g. "are you in the office today?" ). Therefore I thought quickfilter would have found that display names. But it fact it only found this word within their messages' bodies.
Depends on: 243631
After that bug #243631 was landed, this issue, for me, is a bug and not an enhancement, because when I see "John Doe" on messages list and I search for this displayed name I can't find anything... and this confuse me (because I must remember email if the name is displayed?)
No longer depends on: 243631
Severity: enhancement → normal
Version: 3.0 → Trunk
Here's a screenshot showing a typical problematic case. A colleague of mine, Nicolai, has a separate role as our wiki administrator, and uses the same e-mail address, but different names, in the From header to send out personal and wiki-related mail. The actual name from the From header is listed in the message list, but the name associated with his e-mail address in my address book is listed in the message preview pane. This is confusing and inconsistent.
(In reply to Tristan Miller from comment #17) > Created attachment 555041 [details] > Screenshot showing mismatch of name in message list and message view > Here's a screenshot showing a typical problematic case. Tristan, thank you for the screenshot, which illustrates the original problem of this bug as described in comment 0. However, I think with bug 243631, things have changed, and that screenshot is no longer possible starting from TB 5+: User now has a choice between three options: [Terms used: AB's display name = display name as specified on Address book card; From:-header's display name = display name as specified in the real From:-header of the message source] 1) use AB's display name without email in both header pane and message list (default): Tools > Options > Advanced > Reading and display > [x] Show only display name for people in my address book (checked, default) AB card > Contact > [x] Always prefer display name over msg header (checked, default) 2) use From:-header's display name without email in both header pane and message list (optional): Tools > Options > Advanced > Reading and display > [x] Show only display name for people in my address book (checked, default) AB card > Contact > [ ] Always prefer display name over msg header (unchecked, user-set) 3) use From:-headers display name + email (the full, real From:-header) in header pane and From:-headers display name without email in message list (optional): Tools > Options > Advanced > Reading and display > [ ] Show only display name for people in my address book (unchecked, user-set) AB card > Contact > [ ] Always prefer display name over msg header (unchecked, user-set) 3a) Arguably, option 3 does not work as expected, because user deliberately chose to show display name AND the email address (NOT Show only display name...) but we don't show the email address *in the message list*. If the email address is relevant for a user, it's likely he wants to see it in both spots, so we might need a bug for that (though a better, fully customizable solution might be optional columns or a column with customizable column pattern). 3b) Note that user has no way at all to actually show the email address in the message list if From:-header contains a display name, which is clearly a missing feature (could be solved with optional From-email-only column). We don't even show the email for people not in the AB yet. Option 4 is broken: 4) use AB's display name + email in header pane and message list (optional): Tools > Options > Advanced > Reading and display > [ ] Show only display name for people in my address book (unchecked, user-set) AB card > Contact > [x] Always prefer display name over msg header (checked, default) There are two current problems with option 4: 4a) same as 3a), we should show the email in the message list, too, to keep both spots in sync (or provide alternative ways of doing so) 4b) Bug: "[x] Always prefer (AB's) display name over msg header" is simply ignored, we show the From:-header's real display name in both the header pane and message list (need to check if we have a bug for that). Another problem: 5) Need a *global* option for "[x] Always prefer (AB's) display name over msg header", because it's NOT the same as the other global option that we currently have ("[x] Show only display name for people in my address book"). What if I want that setting turned off for *all* of my contacts? The global option also needs a way of temporarily or permanently overriding the per-card setting, perhaps a "apply to all cards" button. I think we need to clarify the UI and the behaviour: As a matter of fact, there are two aspects that we toggle for two places, so to get this right in terms of customization, we need to provide for a minimum of 4 combinations: * always prefer AB's display name: true/false (2 options). Note that this is only about the display name, not about showing the email address. * also show email address ("Show /only/ display name"): true/false (2 options) That's 2x2 = 4 combinations as listed above, under the assumption that we use the same style for header pane and message list (currently inconsistent). Furthermore, we should consider making the message list presentation of the sender column more customizable, either by offering optional columns with different patterns or by offering a column where the pattern can be customized. > A colleague of > mine, Nicolai, has a separate role as our wiki administrator, and uses the > same e-mail address, but different names, in the From header to send out > personal and wiki-related mail. The actual name from the From header is > listed in the message list, but the name associated with his e-mail address > in my address book is listed in the message preview pane. This is confusing > and inconsistent. I think that particular inconsistency has been fixed, and you could use option 2) if you want the From:-header's display name without email address both in the header pane and the message list.
The problems of my comment 19 are beyond the scope of this bug and need to be solved elsewhere (not in this bug). Let's just take comment 19 as a detailed point of reference for the current behaviour, which helps to understand the remaining problem of this bug and to eliminate wrong/outdated descriptions of this bug as in parts of comment 0 and comment 17.
(In reply to Thomas D. from comment #10) > The wanted-thunderbird+ flag should be set for this bug, as it's a > considerable and confusing UI bug that significantly affects the > possibilities and efficiency of quick-filtering. What are the procedures for requesting "wanted-thunderbird+"? The scope of this bug is bigger than described in comment 0: We have the same problem for display names in From, To, CC, or BCC fields (in the following, I'll refer to these as XXX-headers). Plus, per comment 15, because of bug 243631, this bug is now worse than before: By default, we now hide the real XXX-header's display names entirely and replace them with AB's display names as specified by user on AB cards, both on header pane and message list (as described in comment 19, option 1; syncing of both UI parts was introduced by bug 243631, I think). So if user filters for a display name, he'll obviously filter for *AB's display name* as we cannot expect him to use crystal balls, view message source, or tweak advanced settings just to find out about the real XXX-header's display name as specified by sender and thus not under user's control. However, quick filter only searches *real XXX-header's display names* and does NOT search AB's display names. Hence, for any messages where AB's display name is even slightly different from XXX-header's display name (and notwithstanding co-incidental "false" positives from other parts of the message): Quick filtering for AB's display name will *always* fail, and user now has *no* easy way at all to find out about a sender's display name that will actually work for filtering (unless we expect him to use crystal balls, view message source, or tweak advanced settings). We might be lucky that this problem is hidden for many cases where real XXX-header's display name coincides with AB's display name, yielding "false" positives. However, there are a lot of everyday scenarious why users might have AB display names that are different from XXX-header display names, e.g. the scenario mentioned in duplicate bug 706415, comment 0: > For instance, people frequently remove special characters from their names > to make it easier for international readers and for example, specify > "Gregory X." in their email client instead of "Grégory X." > > So typically, if you add this person to your address book you will probably > want to write it the right way : the name in the address book will be > different from the name in the mails themselves. > > Actual results: > Emails do not appear in the quick filter results if you type the contact > name manually set in the address book. Worse, if Gregory decides to *change* his XXX-header display name over time (e.g. from Gregory to Grégory), TB will cause even more quick filter confusion as we will show *some*, but not all of the matching messages for either version of the display name, which in terms of usability is actually worse than showing none. Anyway, for any intentional modification of display name in AB, we'll fail. This is basic functionality, and it's badly broken.
Severity: normal → major
Summary: Quickfilter ignores searches for friendly display names from address book contacts / inconsistent UI displaying addresses in message list vs. message reader → Quickfilter ignores searches for friendly display names from address book contacts (no or incomplete results for From, To, CC, BCC)
Whiteboard: [needs followup bugs for comment 6 and comment 19]
Summary: Quickfilter ignores searches for friendly display names from address book contacts (no or incomplete results for From, To, CC, BCC) → Quickfilter ignores searches for friendly display names from address book contacts, as displayed on message header and message list by default (no or incomplete results for From, To, CC, BCC)
Comment on attachment 555041 [details] Screenshot showing mismatch of name in message list and message view The screenshot of comment 17 is obsolete per comment 19.
Attachment #555041 - Attachment is obsolete: true
Whiteboard: [needs followup bugs for comment 6 and comment 19] → [needs followup bugs for comment 6 and comment 19][gs]
Bug 118624 requests the same for Address book quicksearch/quickfilter.
(In reply to Thomas D. from comment #25) > Bug 118624 requests the same for Address book quicksearch/quickfilter. Not exactly the same though, because so far it's about nickname, not display name.
Same problem of user confusion because of this bug also raised here: https://support.mozillamessaging.com/en-US/kb/quick-filter-toolbar/discuss/1049
I came across the same bug. It is really confusion that you cannot quick filter for the display name from the address book of someone who does not have his name in the header. Especially if it is shown in the list view. I already missed some important emails because of this.
for me this bug is the worst thing in thunderbird. i can not believe, that this is not fixed in the last 7 years :(
I'd like to get this bug fixed. Is there a way to pay or sponsor somebody to get this fixed? I'd like to do us all a favor and pay for it ;)
I can give you an idea, how to resolve this. You should add a checkbox under quick search called "Address book". In this mode, when you input some piece of text into quick search - it searches in address book first and then all e-mail addresses are taken out of all matching address cards by that search (not only display name, but all fields from address book including e-mails). Then those e-mails are used to search inside current folder in checked fields: recipient, sender, title, body. So you get the following chain: you search for "John" > you get results from address book for John Doe and John Smith and take all their e-mails from their address cards and search them inside folder > you get a list of e-mails from John Doe and John Smith under all e-mails that are known to address book. Of course you miss other e-mails, but you can combine search and also search for John inside folder and if some of results collide with address book - prefer address book display name. That's all.
Actually you can bypass that "Address Book" search and just integrate this inside search. This system should work silently and smoothly without the need to configure. You may add a checkbox inside options, for example called: search for display name in quick search (slower).

(In reply to Magnus Melin [:mkmelin] from comment #4)

I doubt it's worth the effort to implement.

Is that still your opinion? I can regularly not find Berna since the e-mail header has her as "ba", but due to the address book entry she is shown as Berna.

Flags: needinfo?(mkmelin+mozilla)

This is pain... 12 years, c'mon!

I guess it would be useful.

Flags: needinfo?(mkmelin+mozilla)

My STR

A.

  • I have account settings for sent messages to be kept in Inbox
  • contact Joe with display name containing "text"
  • send email to Joe, Joe responds (therefore both emails are in Inbox)
  • quick search on "text"
    Results: sent message is in quick search results, received message is not shown

B. move sent message to another folder
Result: received message is revealed

C. click on a different folder, click back to inbox, quick filter on test
Result: received message is NOT revealed

Severity: major → S2
Whiteboard: [needs followup bugs for comment 6 and comment 19][gs] → [needs followup bugs for comment 6 and comment 19][datalossy]

This search has been implemented in TotalQuickFilter 6.2 for Tb78+.

This cunning and significant UX/search logic failure is not acceptable...!
Geoff, any ideas how to implement this with the least technical effort?

Proposal for implementation:

  • In the code, for each folder quicksearch, run a separate quicksearch against relevant Address Book fields.
  • From AB results, extract matching email addresses (including secondary email)
  • Run a separate quicksearch which matches those email addresses against the email fields of the message db.
  • Append found messages to the result of the initial quicksearch.

Or some such.

Flags: needinfo?(geoff)
Priority: -- → P3

That seems reasonable in theory but I don't understand the quick filter code well enough to know what it looks like in practice. It appears you can search for multiple terms with a | separated list, so if you somehow invisibly translated display name into email@invalid|display name it should work.

Flags: needinfo?(geoff)

(In reply to Thomas D. (:thomas8) from comment #42)

This cunning and significant UX/search logic failure is not acceptable...!

This is a high-value ux-papercut with enterprise-relevance. We really need to fix this.
We cannot have a situation where the sender of incoming emails defines whether I can find their messages or not when I search for the very name which Thunderbird presents by default on the message (the display name from user's AB).

Whiteboard: [needs followup bugs for comment 6 and comment 19][datalossy] → [enterprise-relevance][needs followup bugs for comment 6 and comment 19][datalossy]

I reached this bug after a workmate asked me "Why the hell does the quick filter fail?" Current implementation ignoring the name displayed is completely counter-intuitive and frustrating. Blaming the sender makes no solution to the bad image Thunderbird gets from this failure.

By the way, I think this bug is related: https://bugzilla.mozilla.org/show_bug.cgi?id=1336357

After years of not finding e-mails with the contact name and trying to guess the e-mail addresses of my contacts, and today not finding an e-mail for 5 minutes, until I've found out the person send it from their secondary e-mail address, and not the one I'm used to search for, I've decided to look into the problem.
As it seems the issue is known since quite a while. It's a very basic function which is working completely counter intuitive. I guess people would get a lot less support requests from their workmates (as above), or family/girlfriend (my case), if that would work the way people expect it to work.

Between my comment 42 and Geoff's comment 44, I think we have useful ideas for implementation. As user testimony on this bug and 7 duplicates shows, this is really worth fixing. Raising to P2.

Priority: P3 → P2

Just to pile on. It was my wife who hit this and had no idea what was going on or why. Just major frustration when she couldn't find emails she knew existed! I am of course able to figure this stuff out - but most users don't have a (retired) computer scientist in the house :-)

Duplicate of this bug: 1820347
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: