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)
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird1.1
People
(Reporter: asa, Assigned: mscott)
Details
(Keywords: fixed1.8)
Attachments
(1 file, 1 obsolete file)
3.03 KB,
patch
|
Bienvenu
:
superreview+
asa
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•19 years ago
|
||
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
Comment 2•19 years ago
|
||
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.
Reporter | ||
Updated•19 years ago
|
Flags: blocking-aviary1.1? → blocking1.8b4?
Assignee | ||
Updated•19 years ago
|
Flags: blocking1.8b4?
Target Milestone: --- → Thunderbird1.1
Assignee | ||
Comment 3•19 years ago
|
||
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.
Assignee | ||
Comment 4•19 years ago
|
||
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.
Assignee | ||
Comment 5•19 years ago
|
||
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
Assignee | ||
Comment 7•19 years ago
|
||
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
Assignee | ||
Comment 8•19 years ago
|
||
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.
Assignee | ||
Comment 9•19 years ago
|
||
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)
Assignee | ||
Comment 10•19 years ago
|
||
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)
Assignee | ||
Updated•19 years ago
|
Attachment #193103 -
Flags: superreview?(bienvenu)
Updated•19 years ago
|
Attachment #193107 -
Flags: superreview?(bienvenu) → superreview+
Reporter | ||
Updated•19 years ago
|
Attachment #193107 -
Flags: approval1.8b4+
Assignee | ||
Comment 11•19 years ago
|
||
fixed branch and trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•