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)
Tracking
(Not tracked)
REOPENED
People
(Reporter: rhp, Unassigned)
References
Details
(Whiteboard: 5 days relnote-user[nsbeta1+]Have Fix)
Attachments
(5 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M10
Comment 2•25 years ago
|
||
Bulk move mail/news M10 bugs to M11
Comment 4•25 years ago
|
||
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.
Reporter | ||
Comment 5•25 years ago
|
||
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
Comment 6•25 years ago
|
||
OK, I will a new one. BTW, do you know how we did it in 4.x?
Reporter | ||
Comment 7•25 years ago
|
||
MWContext knows all :-)
- rhp
Comment 8•25 years ago
|
||
Ok, let re-introduce MWContext :->
Changing QA assigned to pmock@netscape.com
Updated•25 years ago
|
Target Milestone: M14 → M15
Comment 10•25 years ago
|
||
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.
Reporter | ||
Comment 11•25 years ago
|
||
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
Comment 12•25 years ago
|
||
Taking per selmer's request...
Assignee: ducarroz → jefft
Status: ASSIGNED → NEW
Comment 13•25 years ago
|
||
I have already check in my part of the fix. The message ID (URI) is now stored in the compose fields.
Comment 15•25 years ago
|
||
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
Comment 16•25 years ago
|
||
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.
Comment 17•25 years ago
|
||
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.
Comment 19•25 years ago
|
||
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.
Comment 20•25 years ago
|
||
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.
Comment 21•25 years ago
|
||
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.
Comment 22•25 years ago
|
||
fyi
Mac 2000-060811-17 and linux 2000-060811-m17 exhibits the same behavior as
win32.
Comment 23•25 years ago
|
||
thanks. Move to Future target milestone and add relnote keyword
Keywords: relnote
Target Milestone: M20 → Future
Comment 24•24 years ago
|
||
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.
Comment 25•24 years ago
|
||
> 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.
Comment 26•24 years ago
|
||
Yes, you're right. Sorry.
Comment 27•24 years ago
|
||
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
Comment 28•24 years ago
|
||
ok, david. I'll move back to m18 to coincide w/your nsbeta3 nomination.
Keywords: correctness
Target Milestone: Future → M18
Keywords: relnote3,
relnoteRTM
Comment 30•24 years ago
|
||
*** Bug 56510 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Comment 32•24 years ago
|
||
*** Bug 59235 has been marked as a duplicate of this bug. ***
Comment 33•24 years ago
|
||
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
Comment 35•24 years ago
|
||
*** Bug 52331 has been marked as a duplicate of this bug. ***
Comment 36•24 years ago
|
||
marking nsbeta1+
Keywords: nsbeta1
Priority: P3 → P2
Whiteboard: [nsbeta3-]5 days relnote-user → [nsbeta3-]5 days relnote-user[nsbeta1+]
Updated•24 years ago
|
Target Milestone: M18 → mozilla0.8
Comment 37•24 years ago
|
||
moving to mozilla0.8 milestone.
Comment 38•24 years ago
|
||
*** Bug 64653 has been marked as a duplicate of this bug. ***
Comment 39•24 years ago
|
||
*** Bug 64653 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Keywords: nsbeta3 → mozilla1.0
Whiteboard: [nsbeta3-]5 days relnote-user[nsbeta1+] → 5 days relnote-user[nsbeta1+]
Comment 41•24 years ago
|
||
marking nsbeta1- and moving to future milestone.
Comment 42•24 years ago
|
||
*** Bug 69806 has been marked as a duplicate of this bug. ***
Comment 43•24 years ago
|
||
*** Bug 67130 has been marked as a duplicate of this bug. ***
Comment 44•24 years ago
|
||
Do we really want to minus this bug? That is 6 dups so far. Obviously this is
a problem to people.
Comment 45•24 years ago
|
||
*** Bug 69942 has been marked as a duplicate of this bug. ***
Comment 46•24 years ago
|
||
> Obviously this is a problem to people.
It is! If you really use the product it's very annoying!
-- phil
Comment 47•24 years ago
|
||
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?
Comment 49•24 years ago
|
||
removing the nsbeta1+ for the next round of triaging.
Whiteboard: 5 days relnote-user[nsbeta1+ 2/21] → 5 days relnote-user
Comment 50•24 years ago
|
||
marking nsbeta1+ and moving to mozilla0.9
Whiteboard: 5 days relnote-user → 5 days relnote-user[nsbeta1+]
Target Milestone: --- → mozilla0.9
Comment 51•24 years ago
|
||
*** Bug 71838 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Keywords: nsCatFood → nsCatFood+
Comment 54•24 years ago
|
||
Comment 55•24 years ago
|
||
Comment 56•24 years ago
|
||
I don't think so we need to keep around the following line:
+
//newDraftIdURL += "?fetchCompleteMessage=true";
except this little comment, R=ducarroz
Comment 57•24 years ago
|
||
*** Bug 77246 has been marked as a duplicate of this bug. ***
Comment 58•24 years ago
|
||
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
Comment 59•24 years ago
|
||
> 2) [nocript]
>
> how'd that get by the IDL compiler? can you
...can you log a bug?
Comment 60•24 years ago
|
||
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.
Comment 61•24 years ago
|
||
Comment 62•24 years ago
|
||
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;
Comment 63•24 years ago
|
||
Comment 64•24 years ago
|
||
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.
Comment 65•24 years ago
|
||
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.
Comment 66•24 years ago
|
||
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.
Comment 67•24 years ago
|
||
Updated•24 years ago
|
Whiteboard: 5 days relnote-user[nsbeta1+] → 5 days relnote-user[nsbeta1+]Have Fix
Comment 68•24 years ago
|
||
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.
Comment 69•24 years ago
|
||
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.
Comment 70•24 years ago
|
||
r=bienvenu for the imap part.
Comment 71•24 years ago
|
||
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!
Comment 72•24 years ago
|
||
fixed.
cavin, can you log the bug on the "rapid save of imap draft" problem?
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 73•24 years ago
|
||
The timing issue with save imap draft is logged as #78391.
Comment 74•24 years ago
|
||
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
Comment 75•23 years ago
|
||
*** Bug 141209 has been marked as a duplicate of this bug. ***
Comment 76•21 years ago
|
||
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)
Comment 77•21 years ago
|
||
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
Comment 78•21 years ago
|
||
Well, then, reopening.
pi
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Updated•21 years ago
|
Target Milestone: mozilla0.9.1 → ---
Comment 79•21 years ago
|
||
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
Comment 80•21 years ago
|
||
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.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 81•18 years ago
|
||
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.
Comment 82•18 years ago
|
||
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
Comment 83•17 years ago
|
||
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.
Comment 84•17 years ago
|
||
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).
Comment 85•17 years ago
|
||
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
Comment 86•17 years ago
|
||
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 ago → 17 years ago
Resolution: --- → WORKSFORME
Comment 87•14 years ago
|
||
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 → ---
Updated•9 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•