Closed Bug 156347 Opened 19 years ago Closed 14 years ago
Mozilla does not set or recognize the \Draft flag on IMAP messages
MailNews does not appear to set the "Draft" IMAP flag (defined in section 2.3.2 of RFC 2060 - IMAP v4r1) on drafts saved to a folder on the IMAP server (or to a local folder.) What I did: 1) Logged into my IMAP account with Mozilla Mail. 2) Composed a new message in Mozilla. Saved it but did not send it. Mozilla is configured to save drafts to INBOX\Drafts on the IMAP server. Message successfully saved. 3) Logged into my IMAP account with Outlook Express. 4) Composed a new message in OE. Saved it but did not send it. OE saved draft to local folder, dragged it to INBOX\Drafts on server. 5) Logged into my IMAP account using Horde/IMP-based webmail client. 6) Composed a new message using IMP. Saved it but did not send it. IMP saved draft to INBOX\webmail-drafts. Dragged it to INBOX\Drafts. There are now three drafts in INBOX\Drafts. The two drafts created by OE and IMP show the "draft" icon when the folder is viewed in IMP or OE. Clicking on either message in IMP or OE will bring the message up in "compose" mode. The draft created by Mozilla does not show the "draft" icon, and clicking on the message brings up the standard message display rather than the compose window. Mozilla does not appear to respect the "draft" flag when it is set by other clients -- clicking any of the three messages in Mozilla brings up the message in the standard rather than the compose window. You have to choose "Edit as New..." instead. It would be nice if Mozilla went directly to the compose window when clicking messages flagged as drafts, but that's probably a separate bug.
This is probably dependent on 81340. I don't think it's a duplicate because Mozilla isn't creating the Draft flag locally, either.
Depends on: 81340
Marking New; confirmed here: http://www.emailaddresses.com/forum/showthread.php?postid=153654#post153654 I don't think this depends on Bug 81340: I see this bug but not that one. Reassigning to defaults, as Scott's gone. :(
Assignee: mscott → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Mozilla does not set or recognize the Draft flag on IMAP messages → Mozilla does not set or recognize the \Draft flag on IMAP messages
Any chance that Thunderbird dislpays the IMAP \Draft flag soon ? This is a kind of major oversight.
IMHO, keywords on this bug be changed to: interop mail1 mail6 mailtrack polish
*** Bug 253255 has been marked as a duplicate of this bug. ***
Duplicate Bug 253255 links to trace logs and pinpoints around where in the code the problem appears to be. I see calls to Store; ProcessStoreFlags and SetupMessageFlagsString will flagString.Append("\\Draft ") if told to. Rolfe: Adding keywords: mail6, polish; mailtrack is only to be added by the "Mail Team", whomever that is. mail1 doesn't seem to apply; this isn't about speed/performance optimization.
This patch checks to see if the ImapUrl currently being run was appending a draft from a file. If so, it sets the kImapMsgDraftFlag, such that the \Draft IMAP flag is set on the message.
Comment on attachment 243289 [details] [diff] [review] Unified diff for propose solution to but 156347 --- ../../../../new/mozilla/mailnews/imap/src/nsImapProtocol.cpp 2006-08-10 13:24:08.000000000 -0700 +++ nsImapProtocol.cpp 2006-10-23 21:51:15.000000000 -0700 @@ -5276,6 +5276,11 @@ // convert msg flag label (0xE000000) to imap flag label (0x0E00) if (msgFlags & MSG_FLAG_LABELS) flagsToSet |= (msgFlags & MSG_FLAG_LABELS) >> 16; + // If the message copied was a draft, flag it as such + nsImapAction imapAction; + rv = m_runningUrl->GetImapAction(&imapAction); + if (NS_SUCCEEDED(rv) && (imapAction == nsIImapUrl::nsImapAppendDraftFromFile)) + flagsToSet |= kImapMsgDraftFlag; UploadMessageFromFile(fileSpec, mailboxName, flagsToSet); PR_Free( mailboxName ); }
very nice, Greg, thx for the patch. I'll try it out.
I checked the patch in on the trunk - marking fixed. As the reporter says, we can open a new bug for recognizing the drafts flags. Thx again, Greg.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
fixed on 2.0 branch
You need to log in before you can comment on or make changes to this bug.