User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021122 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021122 I create filters to label mail in color by status. For example, mail of status "replied" get a filter to label it blue. Later, I see that the filter has changed, by itself, to label "read" mail as blue instead of "replied" mail. Reproducible: Always Steps to Reproduce: 1. create filter to label replied mail as blue 2. work on other things 3. come back and see that the filter has changed to label read mail as blue Actual Results: filter labels read mail as blue Expected Results: filter should label replied mail as blue theme happens to be classic
Reassigning it to naving for filter problems.
Assignee: cavin → naving
I believe there's existing report -- status filters have never worked. They weren't applicable until we (recently) implemented manual/after-the-fact filtering. Since filters worked only on New/Unread messages previously, there was no great reason to apply filter on status. Now that we have manual filtering in place, we have to revisit the state of filtering on status. Will look for existing report(s).
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: nbaca → laurel
Summary: filters spontaneously change themselves → filters spontaneously change themselves (Status criteria reset)
*** Bug 186212 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
Summary: filters spontaneously change themselves (Status criteria reset) → filters/views spontaneously change themselves (Status criteria reset)
*** Bug 188166 has been marked as a duplicate of this bug. ***
Mail triage team: nsbeta1+/adt3
*** Bug 193119 has been marked as a duplicate of this bug. ***
*** Bug 194535 has been marked as a duplicate of this bug. ***
There should be a way for finding this Bug searching for "mailviews". I would help solving this if anyone tells me where to search, because I'm not to familiar with the Moz-Source, but quite interested is solving this.
Might it be, that this bug has to do with bug #189890?? I'm afraid it'l take quite a while for me to get used to the code.
*** Bug 195286 has been marked as a duplicate of this bug. ***
Email filtering is, in the last few days, less than useless. Each time I've re-installed a current version, on 2003031408, the filters are somehow altered by the new build and several of them are taken out of service. That's not too bad considering filtering hasn't worked at all for about 3 days. I finally had to remove file msgFilesRules.dat, which in my case is a good sized file, to filter all my legitimate mailboxes plus many filters to send spam to the trash folder. With the filter file I have been using for several months in its proper place Mozilla would lockup just trying to download new email. hrs Harvey R. Savage
Just wondering whether someone is working on fixing this one, so I can stick with Mozilla and not install something else because I need mail filtering that works. Thanks. I greatly appreciate all the volunteer effort that goes into Mozilla, which is actually very stunning.
Assignee: naving → sspitzer
I looked at this, and was not able to reproduce the problem. Is it still occurring with 1.4b/final builds?
I do not use 1.4b. I use 1.3.1 because I am in a "production" environment. It certainly happens in 1.3.1 Since there is no indication it has been fixed, I assume 1.4 still has it.
well, I was not able to reproduce any problem like this in 1.4b - my status filter hasn't changed in several days. This is either an indication that it has been fixed, or that this problem isn't 100% reproducible.
I'm still seeing it in 1.4b. My way to reproduce: 1. Create filter using status = read. 2. Quit Mozilla 3. Start Mozilla and inspect the filter you created. It now uses status = replied instead of status = read. This is on MacOS X. My filters only change when I quit Mozilla, and start it again, not while I keep it running.
ah, ok, now I see it, thx. It's very specific to "read", apparently. Shouldn't be hard to fix. I don't think it's going to account for the other strange behaviour described here, though.
taking, fix coming up.
Assignee: sspitzer → bienvenu
Comment on attachment 123281 [details] [diff] [review] proposed fix r/sr/a=sspitzer very odd, we must never have tested this code.
I'm guessing there are bugs logged by nbaca that will be fixed by this.
QA Contact: laurel → nbaca
Target Milestone: --- → mozilla1.4final
*** Bug 199464 has been marked as a duplicate of this bug. ***
Created attachment 123300 [details] [diff] [review] new and forwarded switched the ui for picking a status switched new and forwarded, from what I can see.
Created attachment 123304 [details] [diff] [review] proposed fix not switched, just wrong. This seems to work.
Attachment #123300 - Attachment is obsolete: true
Comment on attachment 123304 [details] [diff] [review] proposed fix r/sr/a=sspitzer
fix checked in (that last patch wasn't quite right - I changed the 105.... to 65536 so I think it's finally right).
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
*** Bug 196787 has been marked as a duplicate of this bug. ***
If it is now fixed, how do I get a version of Mozilla that includes the fix?
download tomorrow's daily build (5/15/03), from www.mozilla.org, aka Nightly Builds.
*** Bug 205813 has been marked as a duplicate of this bug. ***
Trunk build 2003-05-20: WinMe, Mac 10.1.5, Linux RH 8 Verified Fixed. Views: Status|News, Status|Read, Status|Replied, Status Forward retained the criteria. Filters: Status|Replied, Label message as Blue retained the criteria.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.