Build ID: > Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 IMAP email "replied" status is not set if reply message is saved as draft, draft is edited, then sent This is spin-off of bug 268589 comment #1. [Steps to reproduce] (0) Two mails are held in Inbox of IMAP account. draft folder is "Drafts" of this IMAP account. (1) mail-1 (1-1) Reply, Send (1-2) Restart Tb, Check mail-1 status (bypas of Bug 518581) => Replied is set (2) mail-2 (1-1) Reply, Save as draft, exit mail composition. (1-2) Edit draft, Send (1-3) Restart Tb, Check mail-2 status (bypas of Bug 518581) => Replied is not set

(In reply to Magnus Melin from comment #1) > *** This bug has been marked as a duplicate of bug 522336 *** Why dup? I can't see string of IMAP in that bug at anywhere. See also bug 710584, please. If bug 522336 is for local mail folder/local draft folder case in Tb 3, bug 522336 is already worksforme in Tb 8, and bug 710584 is successor. I believe local folder case and IMAP case should be analyzed separately because; If local mail folder, replied status setting is based on offset of mail data in local mail folder. And Replied status is saved in .msf and written in X-Mozilla-Status: header if local mail folder. However, replied status is stored as IMAP flag of \Answered if IMAP. > uid store 12087 +Flags (\Answered) > (12087 is UID of replied mail) Even though "UID of IMAP folder" corresponds to "offset in local mail folder" and same process is applied to replied status setting, draft save/edit draft process is different between local mail folder case and IMAP case. Note: Deletion of old draft is done based on offset if local mail folder file. Deletion of old draft mail of IMAP is based on UID if UIDPLUS is supported, but it's based on Message-ID if UIDPLUS is not supported(IMAP serach for Message-ID is used).

Since it applies to both imap and pop i don't think we need separate bugs for it, it just makes things more confusing. Most likely the marking logic isn't getting called at all, so the implementation details are not relevant - if there were special cases when it did work then separate bugs would be warranted. I'd dupe bug 710584 too.

(In reply to Magnus Melin from comment #3) > so the implementation details are not relevant If so, why next difference occurs in Tb 8? Reply, Save As draft, exit composition window, Edit draft, Send. (this is STR of bug 522336) (a) Replied mail in POP3 folder, Drafts folder of the POP3 account => Replied is set (reported in bug 710584) (b) Replied mail in IMAP folder, Drafts folder of the IMAP account => Replied is not set set (this bug) (c) I additinally checked. Replied mail in IMAP folder, Drafts folder of Local Folders => Replied is set (same result as above (a)) I couldn't see data like next in .msf file for IMAP Drafts folder, although I could see this data in .msf file of local Drafts folder. > <(96=imap-message://boyacky%40rocketmail.com@imap.mail.yahoo.com/INBOX#230) > (97=replied)(98=id1)>[-0:^80(^88=10)(^8A=0)(^8B=21)(^82^8D)(^85^8E) Why phenomenon like this can be applied to both imap and pop3 commonly? I suspect that problem is in "Save As Draft, even when save just after Reply" of IMAP Drafts folder, because "Save as draft just after Reply" looks to work if local Drafts folder as expected, and because replied status is actually set as expected if local Drafts folder. For bug 710584(report for local Drafts folder case) [STR of bug 710584] (1) Reply, (2) Save as draft, (3) Exit, (4) Edit draft, => (5) Save as draft, (6) Exit, (7) Edit draft, (8) Send => replied not set ( if => (5x) Send, replied is set for mail in local Inbox and in IMAP Inbox ) This indicates that problem is in (5) and/or (7). I believe processing these different problems in single bug, which is already WORKSFORME with STR of the bug in Tb 8 if local Drafts folder, will make problem analysis complex & difficult and will produce much confusing. Anyway, I opened this bug 710586 and bug 710584 in order to completely rule out problem of bug 268589 comment #1 and problem of bug 268589 comment #3 from bug 268589. So I stop commenting in already dup'ed this bug. Please continue anything in bug 522336. "To utilize my test results in two dup'ed bugs or not" is up to developrs.

Because it's still unclear for which case bug 522336 was opened and by which case that bug was confirmed even two years after bug open, I re-opened bug 530528 and dup'ed this bug to bug 530528 which is apparently for IMAP draft folder case.

(In reply to Magnus Melin from comment #3) > Most likely the marking logic isn't getting called at all, so the implementation details are not relevant Aha, you were talking about "implementation detail in replied mail folder" but I was talking about "implementation detail in drafts folder". You: because marking logic isn't getting called at all, it's common in pop3 mail folder and imap mail folder. Me: because marking logic doesn't seem getting called only when imap drafts, it's imap drafts folder specific problem. After regression window check for next, If replied status was set even if IMAP draft, it was in which build. When IMAP draft case was regressed, if actually set in IMAP draft case. Regression in local draft case actually exists or not. I could understand what happened on Tb builds in the past, and what kind of bad actions had happened in that bug. And I could know why I couldn't see replied status when IMAP folder with any Sm/Tb builds which I used in the past. I didn't use IMAP while Tb 3.0aXpre/3.0bXpre era, so I had no chance to see replied status when IMAP draft case. You look to have understood problem correctly since initial because you pointed bug 128996 immediately after bug open of that bug and you added "IMAP only" in bug summary immediately after you read this bug, and because you didn't dup my bug 710584 which is not imap draft only problem(who duped was me). And, if that bug was surely for imap drafts only problem, duping of this bug to that bug was perhaps correct. However, that bug had problems: (1) original bug report : IMAP draft case or not is still unclear, even after two years since bug open. (2) confirming of that bug : IMAP draft case or not is still unclear, even after two years since bug open. (3) "Reply, Send Later" case, which is identical to local draft case, was wrongly dup'ed. How can Reply/Send Later case be dup of regression in IMAP draft case only? (4) Comments for local drafts case was added(unfortunately, local draft or imap draft was unkmown until the comment poster recently reported test result with Tb 8.) Because there are some bugs which produce "replied status is not set" and condition and STR of these bugs are different, and because multiple bugs can occur in some STRs of bugs, we need to clarify for which case bug is opened. > ------------ ------------------- ---------- ---------- --------------- > Location of Location of bug 530528 bug 268589 bug 639702 > replied mail saved mail imap draft Compact negative offset > ------------ ------------------- ---------- ---------- --------------- > local folder no save - X X > IMAP folder no save - - - > local folder Outbox(Send Later) - X X > IMAP folder Outbox(Send Later) - - - > local folder local drafts folder - X X > IMAP folder local drafts folder - - - > local folder IMAP drafts folder XXX X X > IMAP folder IMAP drafts folder XXX - - > ------------ ------------------- ---------- ---------- --------------- > - = not applicable, XXX = always occurs, X=can happen, if condition is met > ------------ ------------------- ---------- ---------- --------------- And, if "multiple save as draft/edit draft" or "one or more save as draft/edit draft + Send Later", location of replied mail, location of saved folder, final send operation("Edit draft/Send" or "Send Unsent Messages), are irrelevant to problem(bug 711909, replacement of bug 710584). Bug occurs with any combination of folder types. Magnus, how could you know that original bug report/confirmation of that bug was for imap draft case? I can't afford to duping of my valid bug report at B.M.O for "apparently IMAP drafts folder only problem" to bug of "report for IMAP draft folder case or not is still unclear even after two years since bug open" and "bug report, which is apparently not relevant to IMAP draft folder, is already duped to" and "problem report for apparently local drafts folder case is already contained". So, I transferred your "Keyword: regression" and "IMAP only" to bug 530528, and I dup'ed my this bug to bug 530528.

(In reply to WADA from comment #7) > Magnus, how could you know that original bug report/confirmation of that bug > was for imap draft case? I just assumed so, given that's the "normal" use case (and the one i saw myself).