Open Bug 1116228 Opened 10 years ago Updated 2 years ago

Message Filters applied twice if additional bodies downloaded

Categories

(MailNews Core :: Filters, defect)

x86_64
Windows 8.1
defect

Tracking

(Not tracked)

People

(Reporter: rkent, Unassigned)

References

Details

This issue was discovered trying to get test_imapFilterActions.js working with maildir in bug 1113275, but the issue is unrelated to maildir.

Under normal IMAP operation, message bodies are not downloaded during initial download of headers, but later by autosync processes. However, if there is a filter requiring the body, or if certain other options are set, bodies will be downloaded in the same sequence of operations that download headers, though in a separate IMAP protocol call.

The problem occurs if there have been some downloads that do not require the message body, and now additional downloads require the body. When that happens, then all of the messages in the database that will eventually need their bodies are added to the IMAP download sequence (See nsImapMailFolder::GetBodysToDownload) But then filters are applied to all of those messages, including ones that had previously been filtered when their headers were downloaded. So filtering is done twice on these messages.

This problem may go away when we modify filtering to only fire on UIDLs higher than the previous value.

To demonstrate this, you would probably need to do something like this:

1) Setup IMAP with offline messages disabled.
2) Add a pre-plugin filter to copy all incoming messages to a folder TEST
3) Download a few messages (that will get copied to TEST)
4) Clear "mail.server.default.autosync_offline_stores"
5) Enable offline messages
6) Download a few more messages.

I suspect that what will happen (but have not tested) is that messages that were previously copied to TEST will be copied to TEST again.

If someone discovers a serious user manifestation of this, you can work around this issue by setting the preference "download_bodies_on_get_new_mail".
> This problem may go away when we modify filtering to only fire on UIDLs higher than the previous value.

we now have this with mail.imap.filter_on_new Bug 1320832

I haven't tested comment 0
See Also: → 519083
See Also: → 128581
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.