591796 - QuickFilterBar returns incorrect results list

Status: RESOLVED INCOMPLETE

(Thunderbird :: Search, defect)

Description

[Michael A. Pasek]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

Searching for a particular string (company name) results in the correct number of "hits", but the wrong emails are displayed.  Search was in "Inbox", which was freshly-compacted and "Repaired".  Since this would likely be result in "WFM", I can make available a 'tar' file containing "Inbox" and "Inbox.msf" files (along with the Mac-specific "._Inbox" and "._Inbox.msf" meta-data files).  Full profile(s) backup (tar.gz) is also available.  

I looked for all bugs in the "Search" component (no arguments other than "Client Software", "Thunderbird", and "Search"), but didn't find anything that seemed to fit this description (not anything that was filed in the last 10-11 months, anyway, and I figured there'd be at least ONE "duplicate", but the only one found was Bug 508796; 3.1.2 includes fix Bug 249841).

Reproducible: Always

Steps to Reproduce:
1. Extract "./Inbox" and "./Inbox.msf" files from the tar file into a POP server directory.
2. Enter (without the quotes) "rackspace" in the Quick Filter Bar's text box
3.
Actual Results:  
Observe that there are "6" hits -- 2 incorrect (2 others which do contain the text are not shown)

Expected Results:  
The correct emails would be shown in the results list

I don't use QFB much, but I'm sure this would be a real irritant to others (especially those migrating from TB2, since QFB "replaces" the search with which they're familiar), so have set severity to "major".

Comment 1

[Michael A. Pasek]

Maybe line-folding handling not consistent in search vs. finding the results to display ?

Comment 2

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

Do you still have the tar of the bad folder around?

Comment 3

[Michael A. Pasek]

Yes (it's actually a tar of ALL profiles).  Can I mail it to you ?  It's about 19MB.

Comment 4

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

If you could mail me just the bad Inbox and Inbox.msf, that would be preferable.  Although I am ever so trustworthy, I really don't want to have more potentially private information than is absolutely necessary.  This e-mail address is fine to use.

Comment 5

[Ludovic Hirlimann [:Usul]]

Michael did you send the files to andrew ?

Comment 6

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

Yes, I got them on Monday.

Comment 7

[Wayne Mery (:wsmwk)]

asuth, michael, is it a line folding issue? It should be easy to tell from View Source.

line wrap is the most common issue I've run into.  Some others can be found listed in bug 519202

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to Michael A. Pasek from comment #0)
> Searching for a particular string (company name) results in the correct
> number of "hits", but the wrong emails are displayed.
>(snip)
> 2. Enter (without the quotes) "rackspace" in the Quick Filter Bar's text box
> Actual Results:  
> Observe that there are "6" hits -- 2 incorrect (2 others which do contain
> the text are not shown)

Same questions as one I asked in bug 379988 & bug 576994. 

There are two known problems which surely produces phenomenon of "false positive because body search actually searches message header", (1) bug 697021 (if multipart mail, message header of next mail is searched by body search), (2) bug 700541 (message header data in messae/rfc822 part of the mail is searched).

As you say "company name" and "rackspace", I guess the string of "rackspace" is used in domain mame or mail address. If so, it can appear in message header such as Received: header of many mails. If so, both of above bugs can happen. And, if bug 700541, I'm sure that you refer to message/rfc822 part in wrongly hit mail(mail of false positive). So, I guess bug 697021 is involved in your "false positive" case.

Michael A. Pasek, Which is your case?
  (a) Same as bug 697021, (b) Same as bug 700541,
  (c) Different from these two bugs, (d) Combination of (a)/(b)/(c).
If (c) or (d), can you find bug for same problem as yours in bugs listed in dependency tree for Bug 519202(which is put in Blocks: of this bug)?

See bug 476341 comment #10 for a problem determination/problem isolation proedure in this kind of problems, please. Michael, please don't force me to download test cases of every bug and don't force me duplication test of every bug :-)

> results in the correct number of "hits", but the wrong emails are displayed.
>(snip)
> Observe that there are "6" hits -- 2 incorrect (2 others which do contain
> the text are not shown)

This indicates "2 false positive"(2 wrong hits) and "2 false negative"(2 mails don't hit although they should hit). Can you find mails which don't hit even though they should hit?

Comment 9

[WADA:World Anti-bad-Duping Agency]

> Steps to Reproduce:
> 2. Enter (without the quotes) "rackspace" in the Quick Filter Bar's text box

Question for our future duplication test with your test mail.

In Tb 7, Sender, Recipients, Subject, Body, can be selected at "Filter messaes by:" row(selection is toggld by click), and additional filtering by "Quick Filter:"(enabled/disabled is toggled by click too) is executed at same time.
Which search/filter criteria is enabled in your "Quick Search" by "text box in Quick Filter Bar"?

By the way, "filter/search via Quick Filter Bar" is similar to Search of folder context menu and Edit/Find/Search Messages of menu, as far as search conditions(and online search/local search if IMAP) is appropriately/carefuly set(e.g. search subfolders is disabled).
And, "Saved Search Folder"(Virtual Folder) can be used as alternatve in testing, if search target folder is single folder only. So, solid search target folder/solid search condition can easily be used by Vrtual Folder, if "refresh of Virtual Folder display" is appropriately/timely done(re-open of folder, by click other folder/click the folder aain).
These make our testing easier and efficient, if appropriate search method is chosen.

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to Andrew Sutherland (:asuth) from comment #6)
> Yes, I got them on Monday.

andrew were you able to evaluate the info?

Comment 11

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

(In reply to Wayne Mery (:wsmwk) from comment #10)
> (In reply to Andrew Sutherland (:asuth) from comment #6)
> > Yes, I got them on Monday.
> 
> andrew were you able to evaluate the info?

I believe I had done a first pass of looking for obvious problems and nothing jumped out at me and postponed a deeper investigation.  I've forwarded the file onto you now since it sounds like you have some interest in fixing the problem.  I probably was over-thinking what I needed to look into, so just throwing it in a profile and trying to duplicate may not be a bad start.

Comment 12

[Wayne Mery (:wsmwk)]

I no longer have the files and I think Mike is gone. At least some of the potential cases are caused by existing bugs, so I think we are OK to close this incomplete.