User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 When an email is replied or forwarded, his status usually changed to "replied", "forwarded" or "replied forwarded". If the original email is moved to another folder before the reply or the forward is completely sent (this means between the moment you click on "send" and the moment when the reply or forward is moved to the "sent folder"), this status is lost. Reproducible: Always Steps to Reproduce: 1. reply to an email 2. click on send. While Thunderbird is communicating with the SMTP server, move the original message to another folder Actual Results: the original message is marked as neither read nor forwarded Expected Results: the message should be marked as read or forwarded, no matter in which folder it is. using TB 0.9, build 20041108 on Win XP SP1
The bug issues also, if you save your message into remote-IMAP Drafts-folder: 1. Choose to reply a message. 2. Close the message composition window 3. Thunderbird will ask, do you want to save your message. Select "Save message". 4. Then open the message again from the Drafts folder and send it. 5. The replied-flag is not set :-( Using TB 1.0.2 .
I'm having a more serious symptom following the same steps as the original description (ie. move original message while reply message is sending). In my case I get spurious messages created in the location of original message with no subject/sender/recipient at all. Also the original message will be marked unread in the location where it is moved to. Also the reply message does not send. And the reply message does not get saved in the Sent folder. On one occasion Thunderbird became unresponsive. version 1.0.6 (20050716)
I can reproduce this, also using Drafts. If I begin to compose a mail, and decide to save it to work on it later (or to work around bug 195490 in Thunderbird 1.5b2), the reply flag is lost in the original folder, regardless of what folder the original mail that I'm replying to is in.
*** Bug 362769 has been marked as a duplicate of this bug. ***
Reproduced with TB 2b1-1202, SM 1.5a-1123.
Assignee: mscott → nobody
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → MailNews: Backend
Ever confirmed: true
Product: Thunderbird → Core
QA Contact: backend
Version: unspecified → Trunk
Product: Core → MailNews Core
also occurs with TB v184.108.40.206
still occurs with the current TB (version 8)
As writen in bug 639702, replied mail is pointed by AccountName + MboxName + UniequMailIDinMbox, and "Replied status" is set using this pointer. UniequMailIDinMbox = local mail folder: Offset of mail data in mail folder file IMAP folder : UID of mail assigned by IMAP server This data is seen by "Send Later" and viewing content of .msf file for Outbox(Unsent Message.msf) by text editor. (1-a) mail in IMAP folder, Reply, Send Later, delete any other mails in Outbox, Compact, then view Unsent Messages.msf > =imap-message://email@example.com/INBOX#33) > (91=replied)(92=id12)(93=176|T-000008-Mfirstname.lastname@example.org)> (1-b) mail in local mail folder, Reply, Send Later, delete any other mails in Outbox, Compact, then view Unsent Messages.msf > (8E=ffffffff)(90=mailbox-message://email@example.com/Inbox/VoiceMail/B1#1346) > (91=replied)(92=id21)(firstname.lastname@example.org)> Note: Bug 639702 is for problem of negative value in #nnnn part. So, if replied mail is moved to other folder, pointer is lost. If offset in local mail folder is changed by Compact, pointer is lost too. In worst case, different mail is marked as replied, if other mail's data is placed at the offset after Compact. "Reply, Save As Draft, Edit Draft, then Send" case is different problem from this bug, even if external symptom of "replied status is not set as expected" is same. (2-a) mail in IMAP folder, Reply, Save As Draft, Edit Draft, Send Later, delete any other mails in Outbox, Compact, then view Unsent Messages.msf > =imap-message://email@example.com/INBOX#33) > (91=id12)(92=176|T-000008-Mfirstname.lastname@example.org)> > =mailbox-message://email@example.com/Inbox/VoiceMail#0)(90=id21)(91 > =176|Cisco Unity Connection Messaging System)> (1-b) mail in local mail folder, Reply, Save As Draft, Edit Draft, Send Later, delete any other mails in Outbox, Compact, then view Unsent Messages.msf > =mailbox-message://firstname.lastname@example.org/Inbox/VoiceMail#0)(90=id21)(91 > =176|Cisco Unity Connection Messaging System)> In both cases, (91=replied), which is seen in "Reply, Send Later" case, is not seen in data held in .msf file. So mail sending process perhaps doesn't set "replied status" of the replied mail. Problem is in "Save As Draft" and "Edit Draft", if lack of (91=replied) is reason why replied status is not set. This bug is for problem of "replied status is not set because replied mail is moved" only, as clearly stated in bug summary. Please don't mix different problem in a bug. Please keep "one problem per a bug at B.M.O".
(In reply to WADA from comment #8) > [...] > So, if replied mail is moved to other folder, pointer is lost. > If offset in local mail folder is changed by Compact, pointer is lost too. > In worst case, different mail is marked as replied, if other mail's data is > placed at the offset after Compact. > [...] still it should be possible to update the currently-open compose windows with the new pointer. i think of some kind of message(oldpointer,newpointer) that is sent to the compose window upon a message has been moved. the message only needs to be generated in case a compose window is open so to save effort in 90% of all move/compact/... operations where usually a compose window isn't open. receiving the message the compose window would check if it's pointer equals the oldpointer and in that case update it's pointer to the newpointer.
(In reply to Thomas E. Horner from comment #9) > i think of some kind of message(oldpointer,newpointer) that is sent to the > compose window upon a message has been moved. > the message only needs to be generated in case a compose window is open so > to save effort in 90% of all move/compact/... operations where usually a > compose window isn't open. Why no need in next cases? (a) Reply, Save As Draft, Compact at folder of replied mail, Edit Draft. As seen in comment #1 and comment #3(2/8=25% of comments before I posted), "Saving of reply mail as draft" is also an ordinl operation. How can composition window know offset change in this case? "Offset change notification upon Compact" needs to update draft mail's meta data, unless any offset change history for replied mail is kept until relevant draft mail is sent or deleted. (b) Send Later, and mail is sent after a while. "Send in background" will be enabled as default. See bug 511079 and bugs in depenency tree of the meta bug such as bug 511079. Similar problem as this bug can occur, and same issue as (a) occurs too. I prefer "Unique mail identifier of local mails in whole Tb system", which I wrote in bug 639702 #0, to "offset change notification" like one. Gloda(Global Search and Idexer) is a good candidate of such mechanism.
FYI. I've opened bug 710586 for problem of comment #1(IMAP), and bug 710584 for problem of comment #3(local mail folder, POP3).
I get this using the Magic SLR to delay sending until I want to. Using TB 17.0.3. After writing a message, click Send Later, so it stays in Outbox. Then file the original message to a folder. Then do Get/Send to flush the Outbox. No "Replied" arrow appears. Same goes for Forwarding. This is VERY VERY annoying, as I nearly always file my messages after replying. It's impossible to tell if I've replied to people ! Regards Nigel
You need to log in before you can comment on or make changes to this bug.