1070646 - need test for Bug 751562 - Filters which move emails to folders broke after 12.0.1

Status: NEW

(MailNews Core :: Filters, defect, P5)

Description

[Wayne Mery (:wsmwk)]

reference bug 751562 comment 45 and bug 751562 comment 75.


+++ This bug was initially created as a clone of Bug #751562 +++
Accepted the upgrade to 12.0.1 for Thunderbird on 04/30, after which filters for my POP3 account which move incoming emails to different subfolders are triggered for "organizing" my incoming emails on each restart of the Thunderbird program

Actual results:
The filters which move incoming POP3 emails to different subfolders in Thunderbird are now having problems locating those subfolders since my upgrade to 12.0.1.

The error message reads:

"The folder 'Folder1' could not be found, so filter(s) associated with this folder will be disabled. Verify that the folder exists, and that filters point to a valid destination file."

After receiving the above message when a filter for "Folder1" meets the criteria to move an incoming email to it, I can Edit that filter (which is now disabled), see that the previously saved "Folder1" selection for the "Move to" operation has been blanked out, then reselect "Folder1" and save the filter again. After re-enabling the filter via the filter list checkbox, I can run it manually and it works fine during that Thunderbird session.

However, if I close Thunderbird and reopen it, if that re-enabled filter is triggered for a new incoming email, I will receive the same error message shown above and its folder selection field value will once again be blanked out.

Also noticed a potentially more general issue with filters and folder values within them on 12.0.1:

If I open "Tools" -> "Message Filters" after restarting Thunderbird, any filter which moves files to a folder shows a blank folder value when first I "Edit" that filter. But, closing that filter edit dialog and then re-hitting the "Edit" button from the filter list shows the appropriate folder name in the "Move to" field for that same filter.

Expected results:
The filters which move incoming POP3 emails to different subfolders in Thunderbird should actually move the new emails to folders when a respective filter's criteria gets triggered (e.g., match a From address value, etc.).

Comment 1

[Wayne Mery (:wsmwk)]

aceman, might you be able to develop a patch?

Comment 2

[:aceman]

I'd love to learn to do some tests for filters (could be also useful for bug 755658).
If we need to receive a message from a POP3 server then it looks like the test should be xpcshell.

Can you propose some steps that the test should do? Like I described in bug 755658 comment 0.

Also, are we sure there isn't already a test like this? Can we ask rkent?

Also, is this bug filed to create the crazy hard test Bienvenu was talking about in bug 751562 ? :)

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #2)
> I'd love to learn to do some tests for filters (could be also useful for bug
> 755658).
> If we need to receive a message from a POP3 server then it looks like the
> test should be xpcshell.
> 
> Can you propose some steps that the test should do? Like I described in bug
> 755658 comment 0.
> 
> Also, are we sure there isn't already a test like this? Can we ask rkent?
> 
> Also, is this bug filed to create the crazy hard test Bienvenu was talking
> about in bug 751562 ? :)

yeah. maybe we need a groupthink. 


David :Bienvenu from bug 751562 comment #81
> I started work on a unit test, but I don't have it anymore - My hard drive
> was wiped when I left and I wasn't able to save all my different trees.
> 
> And again, that unit test was for local mail folders, not imap folders,
> which require a completely different setup.

Comment 4

[:aceman]

I meant bug 751562 comment #44 :)
David :Bienvenu 2012-06-25 17:35:13 CEST
>While I was trying to figure out your issue, I was working on a unit test for the bug and found some >other odd things about folder discovery. I'm going to try to reproduce the issue inside TB before doing >a try server build.

Comment 5

[Kent James (:rkent)]

I don't think that you are likely to easily generate a test for the general issues in bug 751562. Briefly reading that bug, the issue was that under some circumstances folder discovery had not been completed before the pop3 filter ran. So the real issue is the timing of folder discovery at startup. Those issues are very difficult to find generically in unit tests, because the startup sequence is often quite different from the real program. Frequently in unit tests, you encounter startup issues just trying to get things to work there at all, so you end up simulating artificially various startup functions.

Still, here is one thought. Either clone or modify one of the existing POP3 filter tests (like test_pop3MoveFilter.js) like this:

1) At startup, before doing any initializations, manually add the folder structure including a subfolder.
2) Test a filter move to that subfolder.

It will be tricky though to get a meaningful test out of this. Personally I don't think this is worth the effort. A more useful activity would be taking existing unit tests and extending them to work with maildir.

Comment 6

[Melody Benson]

Attachment: same problem

Thanks from scunidquiklas1979.