Using may23 commercial trunk build This was found while Esther was verifying bug 81720 (which was a compose issue from bug 81487). Not sure if this will be compose or offline's problem... If you've tried to save as draft offline to an IMAP/inaccessible drafts folder and received a subsequent "can't save to draft folder", when you go back online you won't be able to save a draft (not even New Messages) again to that draft folder within the session. There are a few variations here, Esther found this when going back online with the compose window open, but I've found out that doesn't matter. When verifying, though, we should try a few scenarios. I guess saving as template in the same would have similar problems, too. 1. IMAP account: disable Sent copy pref to keep this simple. Drafts are set to go to the IMAP/online draft folder. 2. Go to mail window, login to IMAP account. 3. Create a new message, save to draft and close it. This is just to check that the online drafts folder is indeed accessible while online. 4. Go offline, don't download. 5. While offline, New Msg. Type addressee, subject, body. Click Save (to draft) or use menu item to save as draft (didn't see a menu vs. button difference in tests done). 6. Error message comes up "unable to save to draft folder". OK the error. Close the compose window. (as mentioned, leaving it open is another variation, same current result). 7. Go online, don't send unsent messages. 8. When online, still in same IMAP account, New Msg. Type addressee, subject, body text. Click Save to save as draft. You get the "can't save to draft folder" message. After exit/restart saving draft online is ok again. Result: Draft folder access error doesn't clear when online again. Can't save new drafts in session when online again.
I'll keep QA assignee on this one, Gary. A confusing one.
Also drafts related bug 64417.
moving to 0.9.2
This really doesn't have to do with offline. If the save fails for any reason (e.g., the server is down), subsequent attempts to save will fail. This is because we're not clearing the copy state on the destination folder in the case where the copy fials.
Fix comes in two parts - first of all, in the imap code, if the attempt to do the copy fails immediately (which means we didn't run a url), then clear the copy state (this allows subsequent copies to this folder to work). The second part is in the error handling in the copy service code. We were clearing the copy request if the copy failed, but that should be done in the NotifyCompletion method, which should get called on errors, via ClearCopyState. ClearCopyState calls NotifyCompletion. Since we have to call ClearCopyState in general or bugs like this will happen, this fix is correct. Can I get a review from Navin, and an sr from Seth? Thanks. Scott, should I ask for approval to check this in from email@example.com, or wait?
I think you should try to get approval from drivers. PDT was interested in seeing this fixed. Hopefully drivers will be too.
r=naving. Not Clearing the CopyState() is causing lot of bugs. hope we can get it right before we ship.
fix checked in.
This scenario OK for mac OS 9.0 and win98, having some trouble with linux. Will try more extensively ... OK for save to online drafts/templates folder from compose window: 2001-05-30-04 commercial trunk build win98 2001-05-30-05 commercial trunk build mac OS 9.0
Here's what's happening with linux. I tried with old and new profile. 1. Saved fine to online draft folder before going offline. 2. Once offline, save to online draft folder fails... we know that. 3. Go back online, compose message and save to draft --> never gets the "unable to save draft" error, message compose window's status text stays at "copying message to drafts folder" forever(waited many minutes), barber pole spinning. Must close the compose window, OK to the "there is mail being sent" alert. Side note here, if you quit the application after this we crash. Reopening...
Laurel, it's gotta be a different problem if it's only happening on Linux.
Well, I thought it probably was (particularly since we don't get any error pop-up), but didn't know if we wanted to go ahead and track the newer results in this bug report or open a new one... your call.
New bug! And not a .9.1 stopper, if we can help it. I'll look at this with Seth tomorrow, but Linux is tough.
linux issue logged as new bug 83387. Marking this one verified.