When a mail is selected in an imap based search folder that was
previously not, three individual searches of the mail are triggered,
from updateAttachementState, updateSignatureState and
updateEncryptionState. Unfortunately they are precisely triggered from
ImapJob::slotGetMessageData which calls msg->fromByteArray with the data
it received from the server as a result of the message being fetched
after selection. During that fromByteArray the message has no UID
header, since the raw mail returned from the server doesn't, and
therefore KMMessage::UID() returns 0, which causes the first (and only
the first) of the three searches mentioned above to fail. The others
succeed, since they are executed asynchronously and already find
the restored uid in KMMessage::UID() when to get to asking for it. This
results in the message being removed from the search folder and
immediately re-added, which makes imap based search folders virtually
unusable.
Should only be a problem in trunk, I think, since only there are search
folders hooked up to messageHeaderChanged(). Right, Carsten?
Now I can read my kdepim commits search folder again. Rainy Saturday well
spent, I guess. Back to Kolab. ;)
|
|
|
