276056 - Filters sometimes fail

Status: RESOLVED DUPLICATE of bug 275190

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Jon Roland]

Out of 22 filters defined on one account, 2 of them sometimes fail to work,
after an upgrade from 1.7.3 to 1.7.5. Both are defined on the Inbox, test for
the Reply-to field containing a string, and move the message to a folder. The
filter works okay when run manually, and sometimes succeeds in normal operation.
One could live with that except that when it sometimes works automatically and
sometimes requires manual operation, the messages don't get into the folder in
the order they were received.

The intermittent behavior suggests there is something that has changed that
allows skipping over an incoming message without thoroughly testing it for the
condition, perhaps a timing issue.

Comment 1

[Jon]

After an upgrade from 1.7.3 to 1.7.5, none of my filters work.

I have 12 filters, of which 8 are enabled.  These are filters like
'"Mailing-List" contains "[e-mail]" -> Move to folder
"[Subversion/]Dev on [e-mail]"'.

Comment 2

[WADA:World Anti-bad-Duping Agency]

Jon Roland(the reporter)'s case(Reply-To:) is new variation of Bug 275190.
Jon([e-mail])'s case(Mailing-List:) in comment #1 is same as
original symptom of Bug 275190.

By the way, there is also a bug for same problem, Bug 275558,
and in additon, there is another bug refers to Bug 275190, which is a bug for
problem after similar situation to this bug(ie. same situation as 275190 and Bug
275558).
Why couldn't you find these bugs before open new bug?

Jon Roland and Jon Foster, don't feel bad by my question, please.
This is question for Bug 274365. 
> Bug 274365 : More easy way to search Bugzilla
>  - generic Product/Component and Resolution/Status for search by users

Above bugs are not too difficult to find, because "filter" and "1.7.5" can be
keys for searcing Bugzilla, and I think, if they are used, not so many bugs hit
then users can easily find them.
However, not.
What did cause difficulty in search?
Terminology?
Lack of Bugzilla's features in search?
Due to recent Product/Component structure change?
User's attitudes? 

Comment 3

[grebo32]

(In reply to comment #2)
> Why couldn't you find these bugs before open new bug?

I experienced this problem but my search found only this bug.

> Above bugs are not too difficult to find, because "filter" and "1.7.5" can be
> keys for searcing Bugzilla, and I think, if they are used, not so many bugs hit
> then users can easily find them.

They are difficult to find. I tried "filter" and "1.7.5" and got 200 hits. So I
narrow my search but did not see the duplicates you refer to.

> What did cause difficulty in search?

You refer to Bug 275558. It is marked Product="Core" but I searched for "Mozilla
Application Suite".

Also, it is marked with Component="MailNews: Filters" but this component is not
available on the Advanced Search form.

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #3)
> You refer to Bug 275558. It is marked Product="Core" but I searched for "Mozilla
> Application Suite".
Thanks for your answer.
Your case is "Due to recent Product/Component structure change", as I expeted...
Currently, "Product=Thunderbird || Mozilla Application Suite || Core || Toolkit
|| some others" is required to search mail bugs, since mailer related components
are separated to multiple products in Bugzilla system recently.
It will easily spoil user's efforts for searching bugs.
This is the main reason why I opened Bug 274365.
Join Bug 274365 to improve searching, please.

Anyway, I think that it's better to keep this bug open for ease of search until
the problem will be fixed, although this bug is apparently DUP of Bug 275190.
So set "Depends on:" to Bug 275190 instead of DUPing.
("Alias:" seems to be used for this purpose but I don't know how to use this field.)

Comment 5

[David :Bienvenu]

duping...

*** This bug has been marked as a duplicate of 275190 ***

Comment 6

[Jon Roland]

The only filters that seem to be affected by this bug on my system are those
defined on the "Reply-to" line, and failure is intermittent. Most of the time
the filter works, and it always works manually. This suggests a timing problem,
and the lack of code to enforce action even if timeout reached. The reports that
it has been solved in 1.8 are reassuring, but we have to ask whether the fix is
reliable, if not based on understanding of why it occurred in 1.7.5.