When composing a message, and invoking "save" every once in a while, it creates duplicate drafts in the Drafts folder. In netscape 4.7x after the newly saved draft is saved, the previous version is deleted. This does not seem to be taking place in Mozilla.

Please tell us which build you are using and on which platform/OS

This is a dupe of bug 11387. This is not entirely obvious, but this here is clearly a dupe of bug 77246 which is a dupe of the former. So duping this bug about dupes;-) pi *** This bug has been marked as a duplicate of 11387 ***

This bug was logged recently April 2002. The dup 11387 was verified as fixed May 2001, reporter what date is your build, we need to know if this regressed. Does not happen with 2002-04-29 linux branch or 20020430 winxp or 20020427 mac 9.1 when in IMAP and draft folder is located on IMAP. Reporter if you are using a current build and a different set up than I, please give steps to reproduce indicating IMAP or POP and where your designated Drafts folder is located. Reopening until reporter gives more information.

My build is 22002041711 I'm using an IMAP server. Drafts folder is on the IMAP server. I'll let you change the status of the bug, if you wish. It is still be occurring.

This is regressed and happening on RC2 as well. It used to be fine on RC1. My drafts folder is on IMAP server. I'm using Mozilla on Windows 2000.

reassign to cavin

I see it once in a while in Linux. Now proper way to reproduce, though. pi

I logged bug 78391 for the same duplicate drafts problem a while back. Not sure if it's happening and/or related to this.

Cavin, your bug is about IMAP. That might not be important, in which case you might want to dupe it on this one which is more general. pi

It's about drafts on IMAP servers. Isn't that what the problem is? It would be nice if someone can reproduce it consistently. I have not experienced it myself so far.

It happens to me in a POP3 account. pi

Hmm, interesting. Prior to my comment #10, drafts on IMAP servers seems to be the problem. It's good to know that it happens on POP3 accounts as well.

This is 100% reproducable for me. I'm using IMAP, windows client. And just installed RC3, and it is still happening there too.

bugzilla@cardozo.org, please provide exact steps how you reproduce it. pi

I'm not the requested person but here's how I can reproduce, using Mozilla 1.0 RC3 on Win2K SP2 using IMAP with the Drafts folder on IMAP: - Compose a message - hit Ctrl-S to save the message (the message appears in the Drafts folder) - make a change (or for that matter, don't make a change) and hit Ctrl-S again (a new copy of the message appears in the Drafts folder)

joeyconnick, do you know what kind of IMAP servers you're connecting to? University of Washington, Cyrus, etc.

Using POP3 (this is not an IMAP issue) I can reproduce it that way. Surprisingly, only two copies are saved. Upon sending the latter one is removed. pi

It's the University of Washington imapd, I believe.

I'm using Mozila (X11; U; Linux i686; de-AT; rv:1.0.0) and it duplicates the message every time I save in the IMAP draft folder. With the POP3 draft folder it works as expected.

I'm also able to reproduce. Windows, Mozilla 1.1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826), drafts folder on a Courier IMAP server. Choosing another IMAP account where the drafts folder is set to the Local Folder's draft folder, composing and clicking save multiple (more than 2) times gives me 2 draft messages, the first of which is static, and the second of which is updated when I change the text in the compose window.

*** Bug 120798 has been marked as a duplicate of this bug. ***

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030117 Still seeing it. BTW: Is this the right component? I'd assume it's a database issue. pi

AFAICS, the first copy (which is not removed from the drafts folder upon sending) is the first save. Any further save goes to the second copy which then is removed. Looking at bug 78391: " This is mainly because the new uid is not returned to the software fast enough before the next Save button is clicked due to some uncontrollable factors like slow network and server performance." This here is not a timing issue. You can take all the time of the world on an ultra-fast connection and still reproduce the bug. Component? pi

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030514 Now it works for me. Can anybody still reproduce it? pi

I still see this bug with Mozilla 1.5a [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030601]. If I save the mail four times, I get four copies in my IMAP drafts folder.

I asked people at de.comm.software.mozilla.mailnews. Nobody with POP3 could reproduce the bug. Someone with IMAP could. For that reason I'll dupe this one onto the more specific bug. pi *** This bug has been marked as a duplicate of 78391 ***

v

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20030924 I do see this problem again using POP3. Reopening. pi

Can reproduce the problem too. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 Windows XP UW IMAP ctrl-s produced a dupe every time.

I see this with tbird 0.8, I think it has to do with my imap server. on a related note, after saving a draft, sending does not remove it. (that might be bug #162847)

here's what I did: 1) started up tbird 0.8, which selected my imap inbox 2) compose a new message, hit "save draft" three times 3) select my "Drafts" folder, which showed three copies of that message.

looks like the server doesn't support uid plus, and we're not looking for the uid of the newly saved message. I turned that code off for sending messages, but it was supposed to remain for saving as draft...

(In reply to comment #32) > looks like the server doesn't support uid plus, and we're not looking for the > uid of the newly saved message. I turned that code off for sending messages, but > it was supposed to remain for saving as draft... how does this bug and bug 78391 relate (if at all)? and (perhaps related) where is the reasoning in the reopening of bug 11387 to which this bug was once duped?

anyone still see this? I haven't seen it in ages (doesn't mean it doesn't exist though).

David, please comment if you disagree => WFM