Closed Bug 654231 Opened 14 years ago Closed 14 years ago

Filters no longer applied automatically to messages on download. Run Filters (Manual) filter works

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 655578

People

(Reporter: tessarakt, Unassigned)

References

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0a2) Gecko/20110501 Firefox/5.0a2 Build Identifier: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0a2) Gecko/20110502 Thunderbird/3.3a4pre I am using nightlies. Since updating to some nightly (I think yesterday's), filters are no longer applied to the inbox on download. They are, however, applied when manually running "apply filters". Reproducible: Always
Summary: Filters no longer applied to on download → Filters no longer applied to messages on download
Anything in the Error console ? Can you find the regression build ?
Component: General → Filters
Keywords: regression, regressionwindow-wanted
Product: Thunderbird → MailNews Core
QA Contact: general → filters
I will try ... At the moment, that computer is unusable because I somehow broke my boot config when upgrading to Ubuntu 11.04 ... Will take at least until the weekend.
OK, the desktop computer is running again (but at home, and I am not). I am looking at the IMAP box using webmail right now, and it's even more strange. First, as an explanation: The webmailer displays messages marked for deletion in gray. I see _some_ messages that have been moved (they are gray), and some that have not been moved ... But I don't know for sure whether my netbook is also on and applies filters. I will investigate further when I am back at that computer.
Hmm, 2011-05-03-03-comm-aurora seems to work until now ... Will have to check the current build again. As said this morning, it does not occur always. Maybe it is only on automatic message downloads ... So, it might be pretty hard to find.
I am seeing this also in Windows 7 since installing Seamonkey 2.1RC1. If I go back to 2.1b3 then the mail message filters function normally. Back to 2.1RC1 and the problem reappears. Mail message filters do not work automatically but function correctly manually.
OK, that's at least a window. But as said, I am no longer sure that it is "always" reproducible :-|
That's true. I have another computer running Seamonkey 2.1RC1 on Windows XP SP3 and the mail message filters function normally.
is 655578 a dup ? I'm seeing this sporadically.
(In reply to comment #8) > is 655578 a dup ? I'm seeing this sporadically. Please type "bug 655578", so that it is properly linkified ... Most of my filters filter on List-Id, so that might indeed have something to do with it. I noticed something else: When I am in another folder and click on Inbox, new mails are fetched, and, IIRC, filters _are_ applied ...
Jens, *I'm still in a stupor this morning) So filters are applied only if you are in the folder? (consistently) jens, ludo, can one of you find the regression range and then compare to see if they are the same? (note - i find no other filter bugs or regressions of this sort filed in the last 55 days)
I think this recent bug fix may be related. https://bugzilla.mozilla.org/show_bug.cgi?id=178870
Ed, why do you think that bug 178870 is related? That patch did very little, and I would not think it affects existing filters or mail filters at all.
Kent, it just seems awfully coincidental that this happened between Seamonkey 2.1b3 and 2.1RC1 (at least to me) and by looking here: https://wiki.mozilla.org/SeaMonkey:Features:2.1 you can see that one of the items changed between b3 and Final (RC1) was related to news filters so I thought it could have adversely affected the mail filters. I am not a code writer or programmer - just an end user.
Hi Ed. Good to know, but that's a big range. Can you narrow it to a one day window using nightly builds?
Wayne, As I said in comment #7 above, the computer I'm using now running XP SP3 does not have this bug but my computer at home running Windows 7 does. I will try to narrow it down when I am in front of that computer.
(In reply to comment #14) > Hi Ed. Good to know, but that's a big range. Can you narrow it to a one day > window using nightly builds? Wayne, Mail message filters function automatically in this build: Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0.2pre) Gecko/20110501 Firefox/4.0.2pre SeaMonkey/2.1pre Mail message filters do NOT function automatically in this build: Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0.2pre) Gecko/20110502 Firefox/4.0.2pre SeaMonkey/2.1pre These are the same dates noted in Comment #1 of this bug.
Thanks Ed 2011-05-01 to 2011-05-02 does not list any promising checkins for seamonkey. but http://hg.mozilla.org/comm-central/pushloghtml?startdate=2011-04-30+03%3A00&enddate=2011-05-02+05%3A00 yields bug 178870. Note, the thunderbird checkin was 2011-04-26. rkent, is your bug 653859 a regression from that time, or simply a new bug?
Blocks: 178870
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regressionwindow-wanted
OS: Linux → All
Version: unspecified → Trunk
Bug 653859 as far as I know is not a regression. To make progress on this bug, I need to be able to reproduce it. It would be very helpful if someone who sees this can give detailed steps to reproduce. We also need more general information, like: 1) IMAP or POP 2) What search terms and filter actions are in the failed filters 3) Is is all filter or only specific filters. Looking through recent checkins, bug 582918 is a riskier change that could cause unforeseen regressions.
Hi Kent, The conditions under which I see this bug are as follows: 1) Windows 7 SP1 but not Windows XP SP3. 2) POP mail 3) Search terms are "To" and "Contains" and then "Move Message to" a folder in my inbox. 4) These are the only filter terms that I use and it affects all three folders that the mail is filtered to - in other words, no mail is filtered using the above search terms. I did no try any others. 5) The messages filter correctly if I run the filters manually. The problem that developed between 2011-05-01 and 2011-05-02 only affects the automatic processing of the mail filters when mail is downloaded.
Sorry, but I am not able to reproduce this (also used Windows 7 with SM 2.1 RC1) Also, Ed's situation (POP3) seems to be quite different than Jens' (which sounds like it is IMAP). I could investigate this pretty quickly if I could reproduce it, but otherwise it is hard to make progress.
(In reply to comment #20) > Sorry, but I am not able to reproduce this (also used Windows 7 with SM 2.1 > RC1) Also, Ed's situation (POP3) seems to be quite different than Jens' > (which sounds like it is IMAP). > > I could investigate this pretty quickly if I could reproduce it, but > otherwise it is hard to make progress. Yes, I am on IMAP. But I am unfortunately not able to consistently reproduce :-(
(In reply to comment #20) > Sorry, but I am not able to reproduce this (also used Windows 7 with SM 2.1 > RC1) Also, Ed's situation (POP3) seems to be quite different than Jens' > (which sounds like it is IMAP). > > I could investigate this pretty quickly if I could reproduce it, but > otherwise it is hard to make progress. Kent, If you have any suggestions that I could do to help resolve this then I'm all ears. I'm limited though to only what an end user could check. What else was changed between 2011-05-01 and 2011-05-02 Seamonkey nightly builds? Thanks.
If this happens fairly reliably for you, then one thing that you could do is to separate the search from the action. Message moves are the most common action, but the most difficult. So add a filter that has the same search term, but a simpler action (like starring or tagging the message) and see if the problem also happens with that filter. Is this 100% reliable for you or intermittent?
quick question for thought (since I messed up my thinking on bug 178870) - why is Jens seeing the regression in builds a day earlier than Ed? (assuming TB 20110430 build works for jens)
(In reply to comment #23) > If this happens fairly reliably for you, then one thing that you could do is > to separate the search from the action. Message moves are the most common > action, but the most difficult. > > So add a filter that has the same search term, but a simpler action (like > starring or tagging the message) and see if the problem also happens with > that filter. > > Is this 100% reliable for you or intermittent? Kent, I will try what you suggest and let you know what happens. It is 100% reliable with any Seamonkey build starting with 2011-05-02.
Kent I changed the filter action as you requested to tag the mail message when filtered rather than move it to another folder. Same results - mail filter does not run automatically but functions normally when run manually.
Kent, I don't know if this helps but over this past weekend (05/21/11-05/22/11) I received some mail messages that should have been filtered automatically on download. ONE message was filtered normally (automatically on download) but the other 50 (or so) did not. I guess I can no longer say that this is 100% reproducible.
(In reply to Jens Müller from comment #9) > Most of my filters filter on List-Id, so that might indeed have something to > do with it. (In reply to Jens Müller from comment #21) > Yes, I am on IMAP. Jens Müller(bug opener), same problem as bug 655578? Do you see your problem with recent Tb releases? (bug 655578 was fixed by Tb 7) > But I am unfortunately not able to consistently reproduce :-( FYI. Because cause of problem seems bug 655578 comment #12, phenomenon looks to depend on actions taken by Tb before custom header processing(List-Id: etc.) for other headers especially for multi-line header(folded header). If so, it may explain inconsistency of problem in your environment. Because bug 184490 exists, opposite phenomenon(run filters on folder fails, even though filter on fetch works) can happen if offline-use=off folder. Because bug 678322 exists, problem on List-Id: may occur if mail has multiple List-Id: headers(multiple List-Id: is permitted? malformed mail?).
(In reply to Ed Novak from comment #19) > The problem that developed between 2011-05-01 and 2011-05-02 only affects the > automatic processing of the mail filters when mail is downloaded. According to bug 655578 comment #11, problem looks to have been generated by check-in to Tb trunk on 4/29. Porting to SeaMonkey perhaps delays several days. And, according to bug 655578 comment #17, check-in of patch for bug 655578 to Tb trunk was 6/17. Ed Novak, do you see your problem with newer SeaMonkey builds?
(In reply to WADA from comment #30) > (In reply to Ed Novak from comment #19) > > The problem that developed between 2011-05-01 and 2011-05-02 only affects the > > automatic processing of the mail filters when mail is downloaded. > > According to bug 655578 comment #11, problem looks to have been generated by > check-in to Tb trunk on 4/29. Porting to SeaMonkey perhaps delays several > days. > And, according to bug 655578 comment #17, check-in of patch for bug 655578 > to Tb trunk was 6/17. > > Ed Novak, do you see your problem with newer SeaMonkey builds? I have not noticed this bug in some time now. I don't know exactly when it stopped occurring.
(In reply to WADA from comment #29) > (In reply to Jens Müller from comment #9) > > Most of my filters filter on List-Id, so that might indeed have something to > > do with it. > (In reply to Jens Müller from comment #21) > > Yes, I am on IMAP. > > Jens Müller(bug opener), same problem as bug 655578? Do you see your problem > with recent Tb releases? (bug 655578 was fixed by Tb 7) With current release, I saw a message moved to a folder based on List-Id: this morning, so I think it works.
Closing as dup of bug 655578 per comments by Jens Müller(bug opener) and Ed Novak, because regression window is very close to that bug. If you saw your problem even after fix of bug 655578, re-open this bug, plase.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.