Closed Bug 128996 Opened 23 years ago Closed 17 years ago

Sending a saved draft does not update the 'Read/Replied/forwarded' status

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha7

People

(Reporter: lux, Assigned: Bienvenu)

References

Details

Attachments

(3 files)

proposed fix
7.23 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
part of the fix
5.48 KB, patch
Details | Diff | Splinter Review
fix for imap case on trunk
6.45 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
Not sure how to create a test case, but here are the steps I took: 1. Click reply to reply to an email. 2. Save the response as a draft and come back to it. 3. Send the draft at a later time (I don't think this requires restarting the browser) The original message which has been responded to is not marked accordingly in the status column.
which OS? can you still reproduce this with Mozilla 1.1beta?
I'm having the same problem as the reporter: 1. Reply or forward a message 2. Save it as draft 3. Send it afterwards (no restarting of mail client required) Bug 150152 and bug 165193 seem to be duplicates of this bug. I'm using Mozilla 1.1 (release build) with Linux, but in the previous two bugs, people with Windows 2000 had the same problem.
*** Bug 165193 has been marked as a duplicate of this bug. ***
*** Bug 150152 has been marked as a duplicate of this bug. ***
Confirming by both dupes and testing in 1.3beta. Also, this is not IMAP-specific.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: other → All
Wouldn't my proposal at bug 103732 solve this a bit?
Aceman: Your proposal sounds excelent. IMO this is a real bug as it makes using Drafts/Send Later unusable when dealing with large amounts of mail.
taking - fix from 103732 might be useable here too.
Assignee: sspitzer → bienvenu
Just reproduced this bug with 1.6b. Bug #128996 is a dupe and #210566 probably, too.
*** Bug 202814 has been marked as a duplicate of this bug. ***
Agreed with comment 9, bug 210566 is probably a dupe at some level.
Comments to this bug have ceased for half a year. As far as I know, this bug is still present in the my 1.7 release on Linux. Is any of you still seeing this bug in recent releases?
I still have this problem with 1.7 (Gecko/20040616) on Windows.
*** Bug 241281 has been marked as a duplicate of this bug. ***
*** Bug 260244 has been marked as a duplicate of this bug. ***
I have a another variant how to loose the "Replied" flag on a replied mail: 1. have your INBOX on an IMAP server (Cyrus in my case) 2. have your Drafts stored in the "Drafts" folder of your INBOX on the same IMAP server (Mail & Newsgroups Preferences) 3. click on "Reply" to answer a mail you received 4. while writing your answer, click once on "Save", but continue writing afterwards (do not close the message window) 5. at the end of your reply, click on "Send" Result: the original mail is still on "Read" but it should be on "Replied"
*** Bug 263991 has been marked as a duplicate of this bug. ***
*** Bug 264398 has been marked as a duplicate of this bug. ***
*** Bug 265435 has been marked as a duplicate of this bug. ***
*** Bug 268079 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
*** Bug 267070 has been marked as a duplicate of this bug. ***
*** Bug 279098 has been marked as a duplicate of this bug. ***
*** Bug 275421 has been marked as a duplicate of this bug. ***
*** Bug 273288 has been marked as a duplicate of this bug. ***
(In reply to comment #24) > *** Bug 273288 has been marked as a duplicate of this bug. *** This bug still appears on v1.7.5 on XP. It greatly reduces the usability of drafts.
*** Bug 285858 has been marked as a duplicate of this bug. ***
Through the autosave function in 1.8b you can see this bug in nearly everyone the newsthread when you need more time to wrote a message as the autosave is set.
I confirm the presence of this bug on Thunderbird 1.5 beta 2 (20051006). I think it could be resolved because it's 100% reproductible and it's creating a big confusion for users.
I have installed the new Version 1.5 Beta1 20050908. Here i can always reproduce this error/bug again. In version 1.0.x it seems solved - or perhaps only in some less cases, so that i a not very sure, if it happend really. BUT in this last version/build the setting of the state of the e-mail in the folder, where the original e-mail reseeds, which i reply to, doesn't change in any case as i see/test at the moment! No change of state respective icon, when i reply and send the e-mail, so sense whether i send the e-mail directly or after saving it and send it later.
this should be fixed in 1.5 RC1, and nightly 1.5 beta2 builds. *** This bug has been marked as a duplicate of 297254 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
I tried it with the latest nightly (20051021), but for me it doesn't work as expected. - Reply to a message - Save as a draft - Later open the message from the drafts folder - Send the message - The original message you replied to doesn't change state. No icon change too.
I confirmed that this is NOT fixed yet.
what I fixed was the case where the message was saved as a draft while the compose window was open, and then sent directly from the compose window. Not the case where the message was saved as a draft, and the compose window closed, and the draft edited. That's still a problem.
re-opening since this was about editing a saved draft and sending.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Attached patch proposed fix — — Splinter Review
remember disposition when saving as draft, and pull that disposition out and use it when sending a saved draft.
Attachment #200767 - Flags: superreview?(mscott)
Summary: Sending a draft does not update the 'Read/Replied' status → Sending a saved draft does not update the 'Read/Replied' status
Attachment #200767 - Flags: superreview?(mscott) → superreview+
fixed on trunk, won't make 1.5
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Thank you for fixing this bug, David! Now that it is done, would you be willing to take it one step further and fix Bug 128072 or Bug 185258. As stated here and in those two bugs, there are still valid reasons to be able to mark/unmark the message replied status manually. And those bugs seem much easier to fix in comparison to this one.
v with TB 1.6a1-1101, Win2K.
Status: RESOLVED → VERIFIED
*** Bug 320572 has been marked as a duplicate of this bug. ***
*** Bug 323341 has been marked as a duplicate of this bug. ***
this came along with bug 204350
Keywords: fixed1.8.1
*** Bug 334797 has been marked as a duplicate of this bug. ***
Kindly check out on Mac OS X
*** Bug 349550 has been marked as a duplicate of this bug. ***
*** Bug 355803 has been marked as a duplicate of this bug. ***
*** Bug 325301 has been marked as a duplicate of this bug. ***
this seems to have regressed on the trunk and on the 2.0 branch. The replied status is no longer changing for imap. I'll try to investigate.
Attached patch part of the fix — — Splinter Review
The first part of the problem is that the code that tries to set ORIG_URI_PROPERTY on the msg hdr for the draft message is failing. In particular, the way we were turning the folder resource URI into a message resource URI didn't work for imap: http://lxr.mozilla.org/mozilla/source/mailnews/compose/src/nsMsgCompose.cpp#2834 This caused us to never find a msg hdr for the draft. I fixed this by letting the folder object for the saved folder (i.e. drafts) generate the message URI instead of doing it by hand. This meant consolidating code with nsMsgComposeSendListener to get the nsIMsgFolder for the saved folder URI. Now we've got a properly formatted message URI. However, the mail database claims there is no msg hdr that maps to the message key for that folder, so we are still failing to set the properties on the msg hdr.
could the header have been removed from the db by the time we try to get the property? That'll remove all the properties. See nsMsgDatabase::RemoveHeaderFromDB
(In reply to comment #49) > could the header have been removed from the db by the time we try to get the > property? That'll remove all the properties. > > See nsMsgDatabase::RemoveHeaderFromDB > I'll look but we're trying to get the hdr from the drafts database when saving the message as a draft, so I don't think we'd be removing the header from the db in that case. I wonder if the header hasn't been added yet.
If the drafts folder hasn't been opened yet, nsImapMailDatabase::AddNewHdrToDB doesn't get called until after I open the drafts folder by hand. If the drafts folder is already open, nsImapMailDatabase::AddNewHdrToDB gets called after CopyListener::OnStopCopy has fired (which causes the compose window to try to save the draft attributes on the hdr). So we never find the hdr.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Reopening branch too, moving to core.
Component: MailNews: Main Mail Window → MailNews: Backend
Keywords: fixed1.8.1
Product: Mozilla Application Suite → Core
I save all my drafts in Local Folders in Thunderbird 1.5, regardless of account type. Even for my IMAP account, I use a local drafts folder for speed and reliability. In case the suggestion is that this is to do with headers being lost when drafts are posted to the IMAP server, this is not the case for me. The bug occurs with drafts that are saved locally, re-opened and then sent. The original message on the IMAP server is not marked as replied.
Summary: Sending a saved draft does not update the 'Read/Replied' status → Sending a saved draft does not update the 'Read/Replied/forwarded' status
This bug is still present in Thunderbird 2.0.0.5, it is drastically reducing the usability of the draft feature.
I'm not really sure why this was so involved to fix, but it seems to work. The first part of the patch (hopefully there's enough context to see what's going on) makes it so when we're creating a compose window from a draft, if the draft header has an original uri property, make sure we don't clobber that later on with the passed in originalMsgURI. The second part of the fix is to deal with the case where we don't have the msg hdr for the saved draft, when trying to save the queued disposition and original msg uri. In that case, we save those properties as pending properties on the header, which means that when we *do* download the header from the imap server for the newly saved draft message, we'll apply those properties to the new header. Which we can then access in the chunk of code in the first part of the patch. I've verified that saving drafts repeatedly does delete the old drafts, and that the queued disposition is applied when the message is finally sent. I believe these changes only really affect imap drafts, but some baking on the trunk would definitely help.
Attachment #273674 - Flags: superreview?(mscott)
Comment on attachment 273674 [details] [diff] [review] fix for imap case on trunk cool
Attachment #273674 - Flags: superreview?(mscott) → superreview+
Status: REOPENED → RESOLVED
Closed: 19 years ago → 17 years ago
Resolution: --- → FIXED
QA Contact: esther → backend
Hardware: PC → All
Target Milestone: --- → mozilla1.9alpha7
Product: Core → MailNews Core
This still does not seem to work with Thunderbird 3.0. Can anyone confirm?
Just took an e-mail, clicked Reply, typed a response, saved the draft, closed the window, re-opened the draft and sent it. Original message not marked as replied. This is Thunderbird 3.0, Win XP, Drafts is in Local Folders, Inbox and Sent Items are on IMAP.
J.M. and Daniel, see bug #522336
(In reply to comment #65) > J.M. and Daniel, see bug #522336 Great, let's go for another 8 years.
See Also: → 1910414

This bug can still be reproduced with Thunderbird 115.13.0, but only in offline mode. I've raised this in a separate Bug 1910414, but feel free to dupe it to this one if appropriate.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: