Open Bug 11387 Opened 25 years ago Updated 3 years ago

[FEATURE] Need to Track Message ID for Replacement on Saving Drafts (multiple copies are saved in drafts folder)

Categories

(SeaMonkey :: MailNews: Message Display, defect, P2)

x86
Windows NT
defect

Tracking

(Not tracked)

REOPENED

People

(Reporter: rhp, Unassigned)

References

Details

(Whiteboard: 5 days relnote-user[nsbeta1+]Have Fix)

Attachments

(5 files)

We need a way for the FE to keep track of an existing message that it may be editing when dealing with a loaded Draft message. When you load a draft, you have to keep a hold on this message ID since this will be necessary to pass back in to the back end so we replace the message being edited and not add a new message. Also, when you send a message that was a draft, you need to delete that message from the Drafts folder.
Blocks: 10791
adding to the main [FEATURE] bug.
Status: NEW → ASSIGNED
Target Milestone: M10
Blocks: 10857
Blocks: 10859
Bulk move mail/news M10 bugs to M11
Target Milestone: M11 → M14
Drafts are not a beta 1 feature, so moving to M14.
Rich, why not just using the compose field messageID. As draft are constructed from a compFields and as the front End never touch it therefore you should be already able to use it to track a draft message! Else I can just add a new field: draftID.
I think that the message id in the comp fields is the long cryptic string but the message ID we need to track is the one that is the ID for the mail store. Does this make sense? I think that we will need to add another field. - rhp
OK, I will a new one. BTW, do you know how we did it in 4.x?
MWContext knows all :-) - rhp
Ok, let re-introduce MWContext :->
QA Contact: lchiang → pmock
Changing QA assigned to pmock@netscape.com
Target Milestone: M14 → M15
Ok, message compose now (no yet checked in) keep a copy of the original draft message ID into the compose field "draftId". When you open a draft message, mime set the draftId. However, we need to do the same when we save a message as draft. We need also to implement all the from end side of the save command. Rich, how to you want to proceed with this feature.
We should chat about this...I'm not sure I understand what you want me to do, but I remember when I filed this bug that I was pretty sure that all the back end work that was necessary was complete. - rhp
Taking per selmer's request...
Assignee: ducarroz → jefft
Status: ASSIGNED → NEW
I have already check in my part of the fix. The message ID (URI) is now stored in the compose fields.
Status: NEW → ASSIGNED
Whiteboard: ETA 05092000
move to M16. Not M15 stoppers
Target Milestone: M15 → M16
There are array of behaviors we need to address. Such as, subsequent save, save as etc. Templates need to be handled as well.
Whiteboard: ETA 05092000 → 5 days
Message key is really what we need to track not the message id. For imap messages, this is the uid. For pop3 and local messages this is the offset of the message in berkerley folder format.
Me again...last message I swear =). The usual story about this is listed as a feature bug which isn't nominated for beta2. That means we either punt it or nominate for beta2 and take to the PDT team for discussion.
Future release, M20 .....
Target Milestone: M16 → M20
Peter - can you check to make sure current functionality is acceptable? Then, I'll move this out to Future milestone for any more work that needs to be done to make this better.
Compare to 4.x. We don't delete drafts after we sent. We don't replacing the draft if we modify it and then save it again.
Thanks Jeff for checking for me. I get the same behavior using yesterday Win32 2000-060721-m17 build. I will check linux and mac just to check those behavior. Lisa, the current functionality is acceptable. We should just make a note in the most common mail issues.
fyi Mac 2000-060811-17 and linux 2000-060811-m17 exhibits the same behavior as win32.
thanks. Move to Future target milestone and add relnote keyword
Keywords: relnote
Target Milestone: M20 → Future
FYI, Windows 4.x behavior. Drafts are removed from Drafts folder once they are sent. We don't replacing the draft if we modify it and then save it again.
> We don't replacing the draft if we modify it and then save it again. Yes, we do. "Ctrl-s" and "Save" do replacing the draft. "Save As" do *not* replacing the draft. We create a new draft. The semantic is the same with most of the windows program. For example, word document. Templates behave the same.
Yes, you're right. Sorry.
if you've used the product, you'll notice a proliferation of draft messages. It's very unnattractive. We need to fix this.
Keywords: nsbeta3
ok, david. I'll move back to m18 to coincide w/your nsbeta3 nomination.
Keywords: correctness
Target Milestone: Future → M18
Keywords: relnoterelnote2
Keywords: mail2
- per mail triage
Whiteboard: 5 days → [nsbeta3-]5 days
Keywords: relnote3, relnoteRTM
*** Bug 56510 has been marked as a duplicate of this bug. ***
removing mail2 keyword.
Keywords: mail2
Keywords: relnote2, relnote3
Whiteboard: [nsbeta3-]5 days → [nsbeta3-]5 days relnote-user
*** Bug 59235 has been marked as a duplicate of this bug. ***
mscott, the same mechanism you used in bug 22158 should be able to handle deleteing Drafts/Templates after they have bend sent/saved. Thanks, mscott.
Assignee: jefft → mscott
Status: ASSIGNED → NEW
Add mail3 keyword so bug considered for 6.5
Keywords: mail3
*** Bug 52331 has been marked as a duplicate of this bug. ***
marking nsbeta1+
Keywords: nsbeta1
Priority: P3 → P2
Whiteboard: [nsbeta3-]5 days relnote-user → [nsbeta3-]5 days relnote-user[nsbeta1+]
Target Milestone: M18 → mozilla0.8
moving to mozilla0.8 milestone.
*** Bug 64653 has been marked as a duplicate of this bug. ***
*** Bug 64653 has been marked as a duplicate of this bug. ***
moving to mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
Keywords: nsbeta3mozilla1.0
Whiteboard: [nsbeta3-]5 days relnote-user[nsbeta1+] → 5 days relnote-user[nsbeta1+]
marking nsbeta1- and moving to future milestone.
Keywords: nsbeta1nsbeta1-
Whiteboard: 5 days relnote-user[nsbeta1+] → 5 days relnote-user[nsbeta1+ 2/21]
Target Milestone: mozilla0.9 → Future
*** Bug 69806 has been marked as a duplicate of this bug. ***
*** Bug 67130 has been marked as a duplicate of this bug. ***
Do we really want to minus this bug? That is 6 dups so far. Obviously this is a problem to people.
*** Bug 69942 has been marked as a duplicate of this bug. ***
> Obviously this is a problem to people. It is! If you really use the product it's very annoying! -- phil
OK, thats 7 dups so far. Removing the "-" from the nsbeta1 keyword so this gets re-considered. Do I need to change the target milestone to "---" as well to get this re-considered?
Keywords: nsbeta1-nsbeta1
Target Milestone: Future → ---
reassigning this to me as QA
QA Contact: pmock → esther
removing the nsbeta1+ for the next round of triaging.
Whiteboard: 5 days relnote-user[nsbeta1+ 2/21] → 5 days relnote-user
marking nsbeta1+ and moving to mozilla0.9
Whiteboard: 5 days relnote-user → 5 days relnote-user[nsbeta1+]
Target Milestone: --- → mozilla0.9
*** Bug 71838 has been marked as a duplicate of this bug. ***
Keywords: nsCatFood
Keywords: nsCatFoodnsCatFood+
reassigning to cavin
Assignee: mscott → cavin
moving to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Attached patch Incorporated review comments (deleted) — Splinter Review
I don't think so we need to keep around the following line: + //newDraftIdURL += "?fetchCompleteMessage=true"; except this little comment, R=ducarroz
*** Bug 77246 has been marked as a duplicate of this bug. ***
this will be great to have! I've got some issues with this patch. 1) fix the typo in your idl file: savedFoldeURI should be savedFolderURI (that will affect your C++, too.) 2) [nocript] how'd that get by the IDL compiler? can you 3) minor nit, fix the spelling of "Retreive", it should be "Retrieve". 4) in MailNewsTypes2.idl, we define the nsMsgKey type, you should be able to change [noscript] attribute unsigned long messageKey; to [noscript] attribute nsMsgKey messageKey; 5) +/* attribute MSG_ComposeType type; */ +NS_IMETHODIMP nsMsgCompose::SetType(MSG_ComposeType aType) +{ + NS_ENSURE_ARG_POINTER(aType); aType is not a pointer. is 0 not legal? If so, use NS_ENSURE_ARG() my guess is that line isn't needed. 6) style nit: + else + // Remove the current draft msg when saving to draft is done. Also, + // if it was a NEW comp type, it's now DRAFT comp type. Otherwise + // if the msg is then sent we won't be able to remove the saved msg. + if (mDeliverMode == nsIMsgSend::nsMsgSaveAsDraft) + { + compose->SetType(nsIMsgCompType::Draft); + RemoveCurrentDraftMessage(compose, PR_TRUE); + } can you do: // comment else if { } or else if { // comment } 7) rv = compFields->GetDraftId(&curDraftIdURL); instead of using a char *, use an nsXPIDLCString, so you won't have to worry about the free. that should allow to reorganize the code to return on failure, and avoid all the nested if statements. 8) rv = msgFolder->DeleteMessages(messageArray, nsnull, PR_TRUE, PR_FALSE, nsnull); is DeleteMessages() synchronous? (I'm not sure). if not, is that a problem when drafts is on your imap server. 9) all that string parsing / appending code has to go. [the stuff before the call to SetDraftId()] you've got the newUid and you've got the saved folder URI. use the RDF service GetResource() to turn the saved folder uri into a resource, and then query interface into an nsIMsgFolder. [we do this all over the code, so you should be able to find out how to do it. but this would be a could time to read the docs on RDF. I can also give you a crash course] nsIMsgFolder has a readonly attribute, baseMessageURI. see nsMsgDBView::GenerateURIForMsgKey() for some to generate a message uri with the key. instead of copy and paste, I'd push the common code into nsIMsgFolder (add string generateMessageUri(in nsMsgKey key) to the nsIMsgFolder interface) and fix your code and nsMsgDBView::GenerateURIForMsgKey() to use it. once all that is fixed, please attach a new patch and explain how you tested it: 10) testing a) did you test with a draft folder on local and on imap? b) on send, do we still remove the most resent draft of the message from the draft folder
> 2) [nocript] > > how'd that get by the IDL compiler? can you ...can you log a bug?
the idl compiler just ignore it, without any warning or error. This was i mistake I did and I asked cavin to fix it as he was modifing the IDL file.
looking good, a few comments: +nsMsgComposeSendListener::RemoveCurrentDraftMessage a style nit: you don't have to continually nest your ifs. that quickly gets out of hand. you can do avoid the hard to follow nested ifs by checking and returning (and asserting) if things aren't right. instead of using kRDFServiceCID, can you use the prog-id instead. + compFields->SetDraftId((const char *)newDraftIdURL.get()); that cast is not necessary. + NS_ENSURE_ARG_POINTER(aURI); + nsXPIDLCString baseURI; + GetBaseMessageURI(getter_Copies(baseURI)); I'd do: nsresult rv = GetBaseMessageURI(getter_Copies(baseURI)); NS_ENSURE_SUCCESS(rv,rv); + nsCAutoString uri; + uri.Assign(baseURI); + + // append a "#" followed by the message key. + uri.Append('#'); + uri.AppendInt(msgKey); + + *aURI = uri.ToNewCString(); you should check if that *aURI is null. if so, return NS_ERROR_OUT_OF_MEMORY; + return NS_OK;
Attached patch Fixed coding style issues (deleted) — Splinter Review
ok, there is a problem. try to compose a message, hit save, make a change, hit save, repeat. for local mailboxes (when the drafts folder is on a pop or local folders) it works fine and I only have 1 version of the message in my drafts folder. when my drafts folder is on my IMAP server, the first time I hit "save" it works fine. the second time works fine, we replace the message. the 3rd, 4th and fifth time, we aren't removing the old message. cavin, do you see that? my imap server is IMAP4rev1 v12.250, which is a UW server, right? I haven't tried our internal imap server.
one more data point: if my draft folder is open in the thread pane when I do all this, the 2nd save works but the rest fail to delete the old copy. so if I hit save 3 times, I get 2 copies. if I'm viewing another folder in the thread pane, none of the deletes work. so if I hit save 3 times, I get 3 copies.
Seth, the UW IMAP server you're running does not return uid right away in the response for the 'APPEND' cmd. So in this case we (pretty smart) issue a SEARCH cmd on the msg id (like 3AE9E052.6040009@netscape.com) to get the uid for the msg we just saved. My guess is that the code which processes the SERACH response does set the m_messageKey in the nsMsgComposeAndSend object (like the code handling APPEND response does). The new code heavily replies on the uid returned from the server when the APPEND cmd is completed. Since uid is never set for the (old/existing) msg the DELETE cmd is never issued, and that's why msgs were piling up in the draft folder. We need to look into the code of handling search response to find solution to the problem. Glad you brought it up, I think there's another problem even with non-UW servers (like ours here) - timing issue. So if you hit the Save button very very fast (for the sake of testing) some older draft msgs may not get deleted. This is mainly because the new uid is not returned to our code fast enough before the next Save button is clicked due to some uncontrollable factors like network performance, server processing speed, etc. This one is a bit harder to solve.
Attached patch Fixed UW server problem (deleted) — Splinter Review
Whiteboard: 5 days relnote-user[nsbeta1+] → 5 days relnote-user[nsbeta1+]Have Fix
Here is the explanation of the fix: What happens is that the backend imap code does process the SEARCH response from the server (ie, handles the new uid) and set m_messageKey in the nsMsgComposeAndSend object. It stores the uid in a list array and uses only the very first value in the array to reset m_messageKey. However, the array is never reset so m_messageKey is always set to the first value in the array even though the new uids are correctly stored in the array (ie, the 2nd, 3rd etc). So the fix is to reset the array right before the SEARCH (uid by msg id) cmd is issued. This way, the first value in the array is guaranteed to be the new uid returned from the server. The change is in nsImapProtocol.cpp.
cavin's fix to nsImapProtocol.cpp fixes the UW problem for me. once we get that part reviewed by an IMAP person, I can sr this bug and land cavin's fix.
r=bienvenu for the imap part.
sr=sspitzer for the whole bug. I'll land the patch today. (It's in my tree and I've been testing it.) again, excellent work cavin!
fixed. cavin, can you log the bug on the "rapid save of imap draft" problem?
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
The timing issue with save imap draft is logged as #78391.
Using build 2001-05-02 on win, mac and linux this is fixed. I tested this with the Drafts folder on IMAP and POP & our default Local. Thanks Cavin we've been waiting a long time for this. Verified
Status: RESOLVED → VERIFIED
*** Bug 141209 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20030924 Many dupes to this bug say that multiple copies of a message are saved in the drafts folder. This is still happening? Reopen or file a new bug? pi
Summary: [FEATURE] Need to Track Message ID for Replacement on Saving Drafts → [FEATURE] Need to Track Message ID for Replacement on Saving Drafts (multiple copies are saved in drafts folder)
Yes, please reopen this bug. This isn't completely fixed. I believe what was fixed was that if you open a draft message and hit save again, it will replace the old one. What still doesn't work is that if you have a newly composed message and save it for the first time, it keeps that compose window open. If you save again from that compose window, then it adds a new draft to the draft folder. It does not replace the already saved message.
Blocks: 16360
Well, then, reopening. pi
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9.1 → ---
Hi, Just a comment, with Mozilla 1.5 on linux, I have not seen the problem including the following by Jonathan. >What still doesn't work is that if you have a newly composed message and save it for the first time, it keeps that compose window open. If you save again from that compose window, then it adds a new draft to the draft folder. It does not replace the already saved message. Four different saving of drafts resulted in only one copy. 1. New message composed and save. Then save again, using both CTrl+S and menu, no new copy, no new copy in drafts folder 2. New message composed and save. Then modify the message in the window that stays open and save again, using both CTrl+S and menu, no new copy in drafts folder. 3. Open an existing draft message, then save. no new message. 4. Open an existing draft message, modify subject in one case and body in another and then save. no new message, the current message is modified. I would resolved it as fixed. Thanks a lot for the fix as I have a tendency of pressing Ctrl+S when I am composing large emails. Regards Amit
Nope, I have verified this as definitely still affecting Mozilla 1.5 on Windows (I doubt the host OS is the factor though - moz 1.4 on linux also fails which is also from after this patch). It fails both (1) and (2) of what Amit tried. However I now see it works with drafts in "Local Folders". So it appears to be something specific to the IMAP backend, which is what I'm using.
Product: Browser → Seamonkey
Due to Netscape Webmail going the non-proprietary IMAP route (after migration to AOL mail), issues such as this have become more important. Some very significant issues relate to Drafts, but no good progress is likely until underlying issues are clean. I use either Moz 1.7.11 or Netscape 7.2 and both have real problems with Drafts.
I get multiple copies in Drafts when connected to a SmarterMail Enterprise Edition 3.3.2439 IMAP server, from TB 1.5.0.7 on WinXP sp2. But now I will use a local drafts folder to avoid the problem until it's fixed. jh
I'd like to drop a line to say I've been experiencing this same bug with the nightly builds for several months now. I'm currently running: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5pre) Gecko/20070707 Thunderbird/2.0.0.5pre - Build ID: 2007070705 My host says they're running Courier 3.0.3 IMAP server. I will also use the local drafts folder until this is resolved.
A small note to add - I am observing this behavior on Linux with Thunderbird 2.0.0.4 but only in offline mode (when I am taking a long time to write a message, the autosave feature creates multiple drafts that never get deleted). Never encountered it when online though (Dovecot IMAP folders on the server side).
can you test a trunk build? ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-trunk/ both this and bg 78391 WFM using thunderbird trunk build
Assignee: cavin → mail
Status: REOPENED → NEW
QA Contact: esther
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120303 SeaMonkey/2.0a1pre
Status: NEW → RESOLVED
Closed: 24 years ago17 years ago
Resolution: --- → WORKSFORME
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.13) Gecko/20100914 SeaMonkey/2.0.8 After several years I am back to SeaMonkey as my mail client. I tend to save longer mail messages I write many times (I am totally paranoid about crashes). It is not 100% clear to me when several copies are saved, it does not happen all the time, but more often than not. Even worse, if I choose to save a copy (actually, I would like to move) in another folder, then this folder is spoiled. I guess this relates to this old bug. Not sure if bug 482836 is related somehow. pi
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: