When dragging an email with Filter active in Postbox, I am getting the error:

"Tried to create a filter 7 times, but it didn't work out"

Error log:

quickFilters 14:2:33.784  [0 ms]  
No targetFolder.msgDatabase!
 ----------
quickFilters 14:2:33.785  [1 ms]  
Cannot get messageHeader for messageId
[2199-329-LI37JS-ORGR87-TUUFKF-AY6CSF-ZB8UJKX-H-M2-20140130-326cdb44ebb7xxx@xxxxx.com]-
attempting rerun()...
 ----------
quickFilters {CREATEFILTER} 14:2:33.785  [0 ms]  
createFilterAsync - createFilter returned: 0

Note: this is caused by a missing msgDatabase on the folder, which should
normally not happen. I am currently working on an alternative method of getting
at the message detail, in case this fails.

The question is whether the user should be informed of this and whether
repairing or opening the folder can resolve this situation.

Created an attachment (id=7773) [details]
2.3.1 prerelease 55

Here is a first prototype that tries to deal with the problem by retrieving the
nsIMsgDBHdr from the messages as they are dropped / copied so we can avoid
asking the target folder (in case its database is locked or invalid). There is
a slight danger that the header information is invalid in the meantime so this
needs to be tested for a while before it can go into production...

Created an attachment (id=7774) [details]
2.3.1 prerelease 58

This version adds backwards compatibility with the QuickFolders addon: when
moving a message to a folder by dragging it to a QF-tab the message Header
might be temporarily not available - this version does some silent retries over
a period of 1 second if this happens. (Typically 100ms should be enough).

Created an attachment (id=7776) [details]
2.3.1 prerelease 74

another version - when dragging messages into the folder tree it is hard to
tell when Postbox exactly does the move when quickFilters reacts to the drag
event, so the filter code needs to be able to restore the missing message
header information from the target folder in case it is invalidated and the
messages were moved into the folder in the meantime. This should be more
resilient than the previous implementation.

This version also implements the filter assistant when using Postbox's
quickmove feature (pushing the [V] key to move messages to a folder)

Created an attachment (id=7778) [details]
2.3.1 prerelease 75

Added one more fallback code for Postbox in case the message database was
invalidated during the displaying of the filter assistant window. This version
will rebuild the necessary message Header data at every point after an
interaction so that it can be safely entered into the message filter edit
dialog.

Created an attachment (id=7781) [details]
2.3.1 prerelease 91

Tries to address the message database not being ready in Postbox, it will retry
after 400ms, for 5 times altogether. This method is better than the previous
method as it actually tries to rebuild the information from the message
database as it can be invalidated in the meantime, which seems to be especially
likely on Postbox.

Created an attachment (id=7787) [details]
2.3.1 prerelease 93

This is the last prerelease before the full release; it is pretty good at
dealing with most of the problems but in POstbox only when you transfer an
email across to a different IMAP account (move a mail to a folder in another
IMAP account) it still fails, because the message Database of the target folder
apparently never gets ready until you open the folder manually. I have written
to the guys at postbox about this problem to find a programmatical solution
against this, and am currently giving an error message that offers two
workarounds. 

I am keeping the bug open in the meantime.

Created an attachment (id=7789) [details]
2.3.1 prerelease 101

In this version, I am grabbing the header information as early as I can and
copy it to a "cloned" area, so even if it is going to get lost during the move
to an IMAP folder the chances are that the filter can be created successfully.
The only exception would be the case when the header information can never be
got, neither from the source folder neither the target folder. 

This case seems to be a much rarer occurrence. With this version I managed to
move emails across different IMAP accounts, both with Postbox and Thunderbird.

This was still not fully solved in version 3.0.1 as I recently got a report
from another user. After the recent change (I wrapped the various Mozilla
functions MsgMoveMessage and MsgCopyMessage) a user found that the preparation
code for the assistant (which captures the Messages List for later processing)
was even called with the Assistant being switched off. When I fixed this I also
discovered that it is better to do the preparation for the "cloned messages"
headers which I have used to make the assistant's data gathering process more
reliable can be done at a much earlier stage; so I added this as first thing
before I call any other code which has to do with invoking the filter assistant
and building a filter.


This should hopefully make this message a thing of the past. I will upload a
new prerelease next.

Created an attachment (id=8129) [details]
quickFilters 3.0.2 Prerelease 3

Major change: I have wrapped the move / copy procedures in Mozilla, so I now I
can make my "safe copied" (clones) of the message headers at a much earlier
stage. This should mean that the messages (and the message database) are not
"locked" in some way by the moving/copying process, so hopefully this will
resolve the problem.

Final Fix: Version 3.0.2 - Released December 5, 2015