353347 - Wrong Quick Search label "Entire Message" must be renamed to "Body" as it does NOT search the entire message! Gross inconsistency with "Search messages" UI where the same search is labeled "Body".

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[John Navas]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

Quick Search "Entire Message" actually searches just the message body, not the headers as well, which is confusing and inconsistent with Edit -> Find -> Search Messages. It should be changed to "Body" for both consistency and reduced confusion.

Reproducible: Always

Comment 1

[John Navas]

With all due respect, this is a *bug*, not a request for enhancement, because the existing text is confusing/misleading and inconsistent with Edit -> Find ->
Search Messages.

Comment 2

[Magnus Melin [:mkmelin]]

It was intentionally changed the other way in bug 249841. (And you know about bug 271222 so...)

Comment 3

[Wayne Woods]

From reading bug 249841, it sounds like the wording was changed to "Entire Message" because this is what it actually does for newsgroups messages.

David and/or Scott: did I understand that correctly? Or is it more than newsgroups? If the former, do you think it'd be acceptable to change the wording so that "Entire Message" is only used for folders in newsgroups accounts?

Comment 4

[David :Bienvenu]

Newsgroup and imap messages, I think, for searching the offline stores. I'm not sure why searching the offline store for imap and news should be different from searching local mail folders...

Comment 5

[Mike Cowperthwaite]

It doesn't appear to me that "entire message" searches *anything* in Newsgroups, at least not those without XPAT support.  Maybe something has just changed recently, but Search Messages and QuickSearch on the newsgroups at my command -- news.mozilla.org  news.opera.com  news.covad.net -- aren't supporting any kind of body search with 2pre-0302.  (This change prevents the "XPAT Not Supported" error message, so it might have been deliberate.)

Maybe code to change the text to "Message body" and then disable that option for Newsgroups would be good...?  I'm not sure what the behavior should be if the QS has 'Body' selected in a folder and then you switch to a newsgroup -- this is more dynamic switching like you're doing at bug 259914, Wayne.

For IMAP (fastmail.fm, anyway), "Message body" is searching the body but not the Subject (again, QS and Search Messages).

Comment 6

[Wayne Woods]

(In reply to comment #5)
> It doesn't appear to me that "entire message" searches *anything* in
> Newsgroups, at least not those without XPAT support.  Maybe something has just
> changed recently, but Search Messages and QuickSearch on the newsgroups at my
> command -- news.mozilla.org  news.opera.com  news.covad.net -- aren't
> supporting any kind of body search with 2pre-0302. 

Yeah, I tried out some newsgroup servers at my disposal and agree. I don't know if the ones I tried support "XPAT" or not. The lack of support for "entire message" / "message body searches goes back at least as far as 1.0 (20041206) (though I don't have any builds from 2005 or early 2006, so maybe it was fixed and broken again between then and now).

One thing I did notice was that if I copy the messages to another folder, it'll happily search them. In which case, "entire message" only searches the message body, not other message fields, which agrees with POP.

> Maybe code to change the text to "Message body" and then disable that option
> for Newsgroups would be good...?  I'm not sure what the behavior should be if
> the QS has 'Body' selected in a folder and then you switch to a newsgroup --
> this is more dynamic switching like you're doing at bug 259914, Wayne.

If it comes to that, I'd favour just switching to the first available option on the menu.

But if message body searching doesn't have to be switched off in newsgroups (i.e. the root of the problem has been fixed since... can anyone who knows confirm this?), I hope we can fix that and restore the proper usage (and menu wording) for all folders.

Comment 7

[Mitra Ardron]

This bug seems to have got lost in a discussion of searching newsgroups. 

The bug is that on local (POP) mailboxes, the quick search says "Entire Message" and its really searching "Body". 

If it can't be fixed - see Bug 271222 - then the text should be changed because it confuses lots of people who think - not surprisingly - that they are searching the Entire Message. 

I presume this is just change on piece of text? 

Of course ideally bug 271222 would get fixed, but that seems to have got lost as well. 

Searching is a real weakness in Thunderbird, lets it down compared to other mail clients, and IMHO is much more important than some of the estoric or visual fixes since people use it all the time, and expect it to work.  Especially see Bug 229142 which relates to the nasty interface of having to specify at least four different search terms lines to get a search to work over an entire message.

Comment 8

[Alakdae]

I've added a patch that resolves this.
See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=271222">Bug 271222</a>

Comment 9

[Thomas D. (:thomas8)]

(In reply to comment #1)
> With all due respect, this is a *bug*, not a request for enhancement, because
> the existing text is confusing/misleading and inconsistent with Edit -> Find ->
> Search Messages.

The importance of this bug should be changed to "Normal" (at least), as this is clearly not an enhancement. Whatever the problems with searching newsgroups may be, just ask yourself one simple question: What is worse?
a) user thinks he has searched "entire message", but some existing results will never be returned because TB just searches the "body"
b) user thinks he has searched "body" only, but in some (rare) cases involving newsgroups there will be some additional results returned because TB wrongly searches the entire message instead of just the body.

IMHO, clearly a) is worse and this is also quite clearly a bug (that could be fixed (well, bettered), after 3 years, with a simple change of a single string.
Furthermore, having just the change of wording as an extra bug here as requested by bug 271222 comment #13 does not exactly make things more handy. In other words, this bug could be resolved duplicate of its parent bug 271222 as any sane fix for bug 271222 will include the change of strings, as has been already attempted by the current patch in bug 271222 (attachment 367056 [details] [diff] [review]).

Comment 10

[Thomas D. (:thomas8)]

As opposed to my comment #9, maybe it's not that wise to make this bug a duplicate of bug 271222 since the main aim of that bug seems to have shifted towards implementing a new quick search feature "Search entire message" as an enhancement. However, the current summary of bug 271222 (""Entire message" quick search criteria is only the body") is misleading and can easily be mixed up with this bug.

Since I didn't get any opposing feedback on my comment #9, I'll take a stab at adjusting the importance of this bug from "enhancement" to "normal", and asking for "blocking Thunderbird 3" on the grounds that this bug will severely undermine the declared goal of TB3 to improve the user's search experience (cf. my comment in bug 271222 comment #40, which belongs here but ended up in the wrong place because of the poor wording of the current summary of bug 271222 as explained above). Furthermore, the 27 votes and 5 duplicates of bug 271222, open since 2004, must be considered votes for this bug 353347, too, as it was branched of that bug as per bug 271222 comment #13 and provides a "minimal solution" to that bug as per bug 271222 comment #5, #13 B) and other comments.  

The good news is that there are works in progress over at Bug 249841 (False positives from message bodies search in newsgroups and IMAP accounts) which means that this bug's comment #2 that cites bug 249841 to explain/justify the wrong labelling will soon become obsolete (hopefully).

Comment 11

[David Ascher (:davida)]

This doesn't block a release, although resolution would be good.

Comment 12

[Thomas D. (:thomas8)]

This bug is not about a cosmetic change, it's a wrong and misleading label for an existing search function, and a gross inconsistence with "search messages" UI where the SAME search is correctly labelled "Body".
The current quick search label, "Entire Message filter", is completely wrong because the underlying quicksearch does NOT search the entire message, but only the body. For all I know, this applies to Newsgroups as well, since bug 249841 has been fixed. The mind boggles at the thought of Thunderbird 3 being released with such a flaw while one of the main benefits of the upgrade is said to be "a better search experience".
Hey, and it's just a bloody LABEL, no code at all, and the needed label already exists in "search messages" UI ("Body"). So I assume this could be fixed without L10n impact, even if we might want to think of a more natural label for this lateron (like "message body", "message text" etc.).
As David Ascher has it in comment #11:
> resolution would be good.
I understand from that that this is wanted-thunderbird3+ --> requesting such.

Comment 13

[Magnus Melin [:mkmelin]]

Err, changing label would always have l10n impact.

Comment 14

[Magnus Melin [:mkmelin]]

Attachment: proposed fix

Make it "Message body filter".
The rest of the changes are just adding const in front of EXPORTED_SYMBOLS where missing.

Comment 15

[Thomas D. (:thomas8)]

(In reply to comment #13)
> Err, changing label would always have l10n impact.

I understand that l10n impact means somebody will have to translate something into other languages. In this particular case, this wasn't be the case because in "Search messages" UI, there is an existing label that is exactly for the same search ("Body"). So I assumed a possible patch could just manually get and copy the translations from that other label where all the needed strings already exist. That was before you added the word "filter" to each label.

But your new label is better and of course it now has l10n impact.
I think "Message body filter" is a sustainable choice as we can later add "Message header filter" and "Entire Message filter" when needed. 
Please find my comprehensive suggestion for a new, consistent and reordered set of QuickSearch Labels in bug 517187.

Comment 16

[Thomas D. (:thomas8)]

Comment on attachment 401623 [details] [diff] [review]
proposed fix

> searchFromOrSubject.label=Subject or From filter
> searchRecipient.label=To or Cc filter
> searchRecipientOrSubject.label=Subject, To, or Cc filter
>-searchBody.label=Entire message filter
>-saveAsVirtualFolder.label=Save search as virtual folder
>\ No newline at end of file

I don't understand this "no newline" thing, can you help me?

>+searchMsgBody.label=Message body filter

Just wondering: All other labels have a name that is similar to the respective QuickSearchConstant, e.g.:
QuickSearchConstants.kQuickSearchRecipient
--> searchRecipient.label
QuickSearchConstants.kQuickSearchFromOrSubject
--> searchFromOrSubject.label

Your new label breaks this pattern, because it is not similar to the QuickSearchConstant (you add "Msg"):
QuickSearchConstants.kQuickSearchBody
<-> search*Msg*Body.label

1) Is it not possible to change string value of existing label like this?
+searchBody.label=Message body filter

Also, none of the constants' or labels' names use abbreviations, so again searchMsgBody.label is different because of "Msg":

2) If value for searchBody.label cannot be changed, then perhaps we could use
+search*Message*Body.label=Message body filter

Or otherwise use different name for constant, I think Andrew has just changed all the constants (names and values) anyway when he revamped everything in quickSearchManager.js:

3) Maybe could change constant's name?
was: QuickSearchConstants.kQuickSearchBody
new: QuickSearchConstants.kQuickSearchMessageBody
+searchMessageBody.label=Message body filter
(cf. Andrew in bug 462578, comment #30:
> Please name the constant along the lines of the accepted [label] text

I know normally you don't touch constants without breaking something, but this time might be different as Andrew has deliberately just changed them already... (cf. bug 462578, comment #30 and bug 462578, comment #32)

Comment 17

[Magnus Melin [:mkmelin]]

>\ No newline at end of file

This is shown in the diff because the original file didn't have a newline at the end (which is should). 

Localization keys must be changed to make sure localizers notice. What the key is is irrelevant.

Comment 18

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

Comment on attachment 401623 [details] [diff] [review]
proposed fix

That's a 'lotta const!

Comment 19

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 401623 [details] [diff] [review]
proposed fix

Message body filter looks good.

Because of this shift in Quick Search (which is good) from 'Search' to 'Filter' I wonder if we should be changing the saveas option to match.  Though "Save filter as virtual folder" doesn't seem to work for me.  Maybe there is other similar wording that works better.

I think this is good to go in for now.

Comment 20

[Mark Banner (:standard8)]

Attachment: Proposed fix - bitrot fixed

This patch just fixes the bitrot the patch suffered as some files moved.

sr=Standard8, carrying forward r=asuth and ui-r=clarkbw.

Comment 21

[Magnus Melin [:mkmelin]]

changeset:   3900:7144ddadc4bf
http://hg.mozilla.org/comm-central/rev/7144ddadc4bf

->FIXED