189890 - Message views setup: restores from "match any" to "match all" after saving settings

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Klaus Wuerflinger]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212

When selecting more than one view filter (more... button) and selecting "match
any of the following", the latter setting restores automatically to "match all
of the following" when viewing the message view settings the next time (after
pressing ok to close the msg view windows). 

Reproducible: Always

Steps to Reproduce:
1. Message views -> customize
2. Add one filter, select "match any..." and press "more..." button
3. Add another filter, press "ok", and "ok" again in main msg view window
4. re-open msg view -> customize, filter will display "match all..." instead of
"any..."
Actual Results:  
see steps

Expected Results:  
see steps

Comment 1

[esther]

Using build 20030119 on linux, I see this too, it's more of a problem than noted
here.  Acutally the frontend is switching back to matching all, but the backend
is still at match any so this it appears this functionality is broken when it's
not(per bug 186182). 

Comment 2

[(not reading, please use [e-mail] instead)]

from my mailViews.dat file:

name="aa"
enabled="yes"
type="1"
condition="AND (subject,contains,aaa) OR (subject,contains,aaab)"

I bet the mixed booleans is part of the problem.

Comment 3

[(not reading, please use [e-mail] instead)]

when I create the view, I have:

name="aa"
enabled="yes"
type="1"
condition="OR (subject,contains,aaa) OR (subject,contains,aaab)"

but when I open it the second time, and then hit ok, I turns into:

name="aa"
enabled="yes"
type="1"
condition="AND (subject,contains,aaa) OR (subject,contains,aaab)"

investigating...

Comment 4

[(not reading, please use [e-mail] instead)]

the problem is with LoadCustomMailView() in msgViewPickerOverlay.js

in order to work with quick search (QS), we set the boolean for the first term 
to be "and", and the front end code uses the boolean for the first term for the 
radio button.

the fix (testing a patch) is to clone the search terms before altering them for 
QS.

Comment 5

[(not reading, please use [e-mail] instead)]

fix in hand, but still improving it.

Comment 6

[(not reading, please use [e-mail] instead)]

Attachment: patch

patch, use a temporary search term array, since we will be modifying it for QS.

Comment 7

[(not reading, please use [e-mail] instead)]

Attachment: update, fix comment and an error in my patch

Comment 8

[esther]

Sorry the possible duplicate is bug 186162

Comment 9

[esther]

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

Comment 10

[Cavin Song]

Comment on attachment 112271 [details] [diff] [review]
update, fix comment and an error in my patch

r=cavin.

Comment 11

[Asa Dotzler [:asa]]

Comment on attachment 112271 [details] [diff] [review]
update, fix comment and an error in my patch

a=asa (on behalf of drivers) for checkin to 1.3beta.

Comment 12

[(not reading, please use [e-mail] instead)]

fixed.

Comment 13

[esther]

verified with trunk builds 20030211 on linux, 20030214 on winxp and maco osx.