391402 - Potential IMAP URL queueing regression

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[Nick Kreeger]

It seems that a certain IMAP Url sequence that I'm using for the new roaming service may have exposed a potential glitch in the IMAP URL queueing setup.

Right before I start to send off a request to save an attachment part from a message (non-cached message), I was calling |UpdateFolder()| on the listened folder (not INBOX). Then I build a to-do list of update messages to process (saving a TOC file is the first step). Then one at a time, I process each message. This was working before the patch to fix bug 381992 was landed. However, afterwords, I can only get the attachment to save correctly if I remove my |UpdateFolder()| call. 

When the |UpdateFolder| call is made, I see the |OnStartRunningUrl| call made in |nsMsgSaveListener|, however I never see any calls made from relatively important libmime functions (like |imeObject_parse_begin()|) or OnStopRequest/OnDataAvailable. As mentioned above, removing the |UpdateFolder()| call fixes the issue and attachments are saved just fine.

A suggested cause of the regression would be the changes from bug 381992.

It should be noted that this has only happened on a queued attachment URL. We have not been able to come up with a usable test-case at the moment (outside of my roaming patch).

Comment 1

[David :Bienvenu]

Attachment: patch to help try to reproduce this

In an attempt to recreate this, I modified the save as attachment code to update the folder first, which will make the save as url get queued. It didn't make the problem occur, though I verified that the save as url is getting queued.

My test case was as follows:

1. turn off memory cache.
2. Select a message with a large (70K) external attachment (a pdf file)
3. Go offline, which kills our cached connections
4. Go back online, right click on the attachment, and save it

At least on Windows, this seemed to work fine. But I'll try some more things.

Comment 2

[David :Bienvenu]

fixed as part of patch in bug 389898