Closed Bug 277842 Opened 20 years ago Closed 19 years ago

virtual folder does not populate if quicksearch selection doesn't match folder search category

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird1.1

People

(Reporter: asa, Assigned: mscott)

Details

(Keywords: fixed1.8)

Attachments

(1 file, 1 obsolete file)

virtual folder created from quicksearch on "entire message" fails to populate if
quicksearch is not set on "entire message" on IMAP account

steps to repro:
1. focus the quicksearch field, select "entire message", and and type in the
letter "a". 
2. if this gives results, then save that as a search folder. if no results, your
mailbox must be empty :-)
3. set quicksearch field to "subject or sender"
4. select the saved search folder and observe that you get no results.
5. switch the quicksearch to "entire message", select some other folder besides
the saved search folder, then select the saved search folder and you will see
results.

results: 
With something other than "entire message" selected in the quicksearch field,
you won't get any results in the saved search folder. 

additional info: this happens regardless of whether the saved search is set to
search online or not.
Tested on Thunderbird 1.0 with two different IMAP servers.
I've investigated this a bit further. If you create a virtual folder with rules
to search on the message body and rules to search on subject or sender, then you
only get results in the virtual folder for either the body or the
subject/sender, depending on the quick search criteria selected. 

This seems like a pretty major failing in virtual folders. Scott, can you take a
look at this? I've got a simple example I can show you on my machine. 
Flags: blocking-aviary1.1?
Summary: virtual folder created from quicksearch on "entire message" fails to populate if quicksearch is not on "entire message" → virtual folder does not populate if quicksearch selection doesn't match folder search category
I've tested this on trunk 2005-06-27 and it shows the same error as described in
the first comment. I haven't tried it for pop accounts but it surely doesn't
work with imap.
Flags: blocking-aviary1.1? → blocking1.8b4?
Flags: blocking1.8b4?
Target Milestone: --- → Thunderbird1.1
Interesting. I see this when I first create the virtual folder. but as soon as I
restart the application, it always works regardless of the value of the quick
search selection type.
hmm, now I don't even have to restart. The first time I try to load the folder I
get 0 matches. But every other time we load it after that, it works. 
asa pointed out another tip to make it easier to see this.

have a couple search terms in the VF which use different criteria.

Note that the virtual folder search only seems to work for the criteria that
happens to match what is selected in the quick search bar
the fix for Bug 298285 may fix this.
Assignee: mscott → bienvenu
It doesn't look like Bug 298285 fixed this for us. 

On my test VF, when the quick search text is set to Subject or Sender, the
results are very fast. When it is sett to Entire Message body, the folder takes
a very long time to load. And the VF is not using any quick search terms so the
value of the menu list should not be effecting loading the VF. And the # of
results is different as well.

using an 8/15 build
I think I found the problem.

http://lxr.mozilla.org/mozilla/source/mail/base/content/searchBar.js#393

We only set the search scope to search online for imap accounts if the quick
search mode == searchbody

We should also walk through the search terms we are going to add, checking the
search type of each one before deciding whether to search online or not.
Attached patch possible fix (obsolete) — Splinter Review
David, what do you think about this solution? Is just checking the body
attribute too specific? Should we be checking for other search attribute values
besides body when deciding to set the scope to online?

I thought it was easier to isolate all of this logic in its own method,
getScopeToUse.
Attachment #193103 - Flags: superreview?(bienvenu)
Attached patch updated fixSplinter Review
simplify the logic a bit based on some comments David made over IM
Assignee: bienvenu → mscott
Attachment #193103 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #193107 - Flags: superreview?(bienvenu)
Attachment #193103 - Flags: superreview?(bienvenu)
Attachment #193107 - Flags: superreview?(bienvenu) → superreview+
Attachment #193107 - Flags: approval1.8b4+
fixed branch and trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Keywords: fixed1.8
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: