thunderbird's "subject or sender" search searches "from" field rather than "sender"

Bug #225797 reported by Robert Persson
4
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Fix Released
Medium
mozilla-thunderbird (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

In the current Thunderbird on Hardy the "subject or sender" search box at the top right of the main window doesn't search the "sender" fields in your mailbox. Rather it searches the from fields.

Steps to reproduce:
* Receive a mail with separate "sender" and "from" fields. The ubuntu-studio mailing list will do this for you (https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users).
* Do a "subject or sender" search for something in the "from" field; it will show up.
* Likewise for something in the "sender" field, but not in the "from" or "subject" field; you won't see it.

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

-> new

The main search and filter strings were fixed in bug 221724. Seems quick search was forgotten. (That and the thread column).

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Created attachment 233465
proposed fix

Change all the remaining thunderbird "Sender" stuff (quick search, thread columns) to "From". From is also what Outlook uses.

Without this fix there is cause for confusion since bug 285474 (which I guess should be marked as fixed) has landed.

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

*** Bug 338748 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Bienvenu (bienvenu) wrote :

Comment on attachment 233465
proposed fix

I'm pretty sure you'd need to change nsMsgDBView.cpp::GetCellText for this to work, since you've changed the name of the tree column. Other than that, I'm ok with this change (though "Subject or From" is a bit awkward)

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Created attachment 234683
proposed fix, v2

Yes, you're right, this patch fixes that. It also takes care of seamonkey.

Also, an unused property "sortBySenderOrRecipientMenuitem" I stumbled upon was removed: http://lxr.mozilla.org/seamonkey/search?string=BySenderOrRecipientMenuitem

Revision history for this message
In , Mscott-mozilla (mscott-mozilla) wrote :

Comment on attachment 234683
proposed fix, v2

Renaming all of these variables, entity names, column ids, etc. seems like over kill.

And most users don't know the difference between from and sender anyway.

Instead, why not make quick search on Sender (or From if we change the UI string) search both the Sender and the From header with an OR search.

Ditto for Subject or Sender.

Most users don't know the difference, quick search should just 'work' for them.

Revision history for this message
In , Chris Moore (dooglus) wrote :

If a quick search for messages containing a certain string in the Sender header returns messages which don't contain that string in their Sender header, then that's not "just working".

Just because you ignorant users doesn't mean you should make broken software.

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

(In reply to comment #6)
> (From update of attachment 234683 [edit])
> Renaming all of these variables, entity names, column ids, etc. seems like over
> kill.

Well since the semantic meaning does change a bit, the entity names should change so localizers will notice, no?

Ok, some variable names were changed just for code consistency. I can skip those changes of course, though I'd prefer changing them if you don't have a strong opinion about it... ;)

> Instead, why not make quick search on Sender (or From if we change the UI
> string) search both the Sender and the From header with an OR search.

Yeah, that sounds like a good idea!

---
Updating summary, quick search is really the smaller part of these changes.

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Created attachment 240930
proposed fix, v3

Changes from v2: made search for From match "Sender:" also.
One caveat: For some reason matching "Sender:" doesn't work for online imap folders.

If you want me to keep the original names, how much of them should I keep?

Revision history for this message
In , Mscott-mozilla (mscott-mozilla) wrote :

Comment on attachment 240930
proposed fix, v3

I'm worried about backward compatibility issues with changing the tree col ID, as this will break folks who have hidden or otherwise re-ordered the senderCol.

That applies to messenger.xul and SearchDialog.xul.

David might have a comment about why searching the Sender header doesn't work for imap folders in quick search. I suspect it's because we don't fetch the Sender header for the message when we are downloading just the header info for imap messages. So the msg hdr doesn't have a sender field.

Revision history for this message
In , Bienvenu (bienvenu) wrote :

right, we don't fetch the "Sender" header unless you've added it to the list of custom headers by creating a mail filter that filters on the Sender header.

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Created attachment 242434
proposed fix, v4

Updated patch, this doesn't touch the tree col ID.

Quick search doesn't match also "Sender:" for online IMAP folders. I'm not sure how to make us fetch that header so it can be matched (if we want to do it in this bug). Besides that it works fine.

Revision history for this message
In , Mscott-mozilla (mscott-mozilla) wrote :

Comment on attachment 242434
proposed fix, v4

Hey David,

Does this code look ok to you? I wonder if we should make the back end search code treat nsMsgSearchAttribValue Sender searches as searches on the From or Sender header for everyone instead of doing a quick search specific thing. Would that make sense?

+ // make quick search for From also match the "Sender:" header
+ if (gSearchInput.searchMode == kQuickSearchFrom || gSearchInput.searchMode == kQuickSearchFromOrSubject)
+ {
+ term = gSearchSession.createTerm();
+ value = term.value;
+ value.str = termList[i];
+ term.value = value;
+ term.attrib = nsMsgSearchAttrib.OtherHeader;
+ term.op = nsMsgSearchOp.Contains;
+ term.booleanAnd = false;
+ term.arbitraryHeader = "Sender";
+ searchTermsArray.AppendElement(term);
+ }

Thanks for leaving the tree columns alone magnus.

I'm going to nominate this for tb2 approval, but we'll want to see some bake time on the trunk first. So I won't plus this right away.

Revision history for this message
In , Bienvenu (bienvenu) wrote :

ugh, I worry that the arbitrary header Sender search is going to mean looking on disk at the headers of each message, which is going to slow things down. My vague recollection is that I'm storing the sender in the msg hdr, but I'm not sure the search code knows that.

Revision history for this message
In , Mscott-mozilla (mscott-mozilla) wrote :

Comment on attachment 242434
proposed fix, v4

pulling back the sr until we look into David's concerns. We might go back to taking this patch but without the From + Sender behavior for quick search...

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

*** Bug 364753 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Mscott-mozilla (mscott-mozilla) wrote :

Comment on attachment 242434
proposed fix, v4

unfortunately this didn't make it in before the string freeze so we can't take this now.

Revision history for this message
In , Mcow (mcow) wrote :

*** Bug 355170 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Created attachment 266917
proposed fix, v5

Unbitrotted the previous patch, and skipping the quicksearch From + Sender behavior. If we still want to do that, we can do it in another bug.

Revision history for this message
In , Philringnalda (philringnalda) wrote :

mail/base/content/SearchDialog.xul 1.24
mail/base/content/mailWindowOverlay.js 1.167
mail/base/content/mailWindowOverlay.xul 1.208
mail/base/content/messenger.xul 1.72
mail/base/content/searchBar.js 1.42
mail/locales/en-US/chrome/messenger/SearchDialog.dtd 1.10
mail/locales/en-US/chrome/messenger/messenger.dtd 1.64
mail/locales/en-US/chrome/messenger/messenger.properties 1.48
mailnews/base/resources/content/commandglue.js 1.273
mailnews/base/resources/content/mailWindowOverlay.js 1.256
mailnews/base/resources/content/mailWindowOverlay.xul 1.330
mailnews/base/resources/content/threadPane.js 1.90
mailnews/base/resources/content/threadPane.xul 1.137
suite/locales/en-US/chrome/mailnews/messenger.dtd 1.215
suite/locales/en-US/chrome/mailnews/messenger.properties 1.141
suite/locales/en-US/chrome/mailnews/threadpane.dtd 1.28

Revision history for this message
Robert Persson (ireneshusband) wrote :

In the current Thunderbird on Hardy the "subject or sender" search box at the top right of the main window doesn't search the "sender" fields in your mailbox. Rather it searches the from fields.

Steps to reproduce:
* Receive a mail with separate "sender" and "from" fields. The ubuntu-studio mailing list will do this for you (https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users).
* Do a "subject or sender" search for something in the "from" field; it will show up.
* Likewise for something in the "sender" field, but not in the "from" or "subject" field; you won't see it.

Revision history for this message
Joel Goguen (jgoguen) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? If this is still a problem for you, please include the Thunderbird version (from Help -> About Mozilla Thunderbird). Thanks in advance.

Changed in mozilla-thunderbird:
status: New → Incomplete
Changed in thunderbird:
status: Unknown → Fix Released
Revision history for this message
Joel Goguen (jgoguen) wrote :

Upstream has fixed this for Thunderbird 3, but it will likely not make it to Thunderbird 2.

Daniel T Chen (crimsun)
Changed in mozilla-thunderbird:
status: Incomplete → Won't Fix
Changed in mozilla-thunderbird (Ubuntu):
status: Won't Fix → Triaged
Changed in mozilla-thunderbird (Ubuntu):
status: Triaged → Won't Fix
Changed in thunderbird:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.