Messages not deleted from Drafts folder [IMAP account] when they are sent if you clicked "Send later"

RESOLVED FIXED

Status

--
major
RESOLVED FIXED
15 years ago
10 years ago

People

(Reporter: bugzilla, Assigned: janv)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

This happens with IMAP accounts

Reproducible: Always

Steps to Reproduce:
1.Compose a new email message
2.Click Save
3.Click File>Send Later
4.Close window
Actual Results:  
Messages are copied to unsent folder but they are NOT deleted from Drafts folder

Expected Results:  
Messages are deleted form Drafts folder and moved to unsent messages
AFAIK, this is correct and by design
(Reporter)

Comment 2

15 years ago
by design? if it isn't a template, why should it not be removed?
(Reporter)

Comment 3

15 years ago
According to Drafts Feature Test Specification
(http://www.mozilla.org/quality/mailnews/tests/sea-mn-drafts.html), drafts
should be removed from Drafts folder after they have been sent. This works
properly with the "Send" function, but with "Send later", they aren't removed
from Drafts folder.
***This also happens with POP accounts***
(Reporter)

Comment 4

15 years ago
Also happens in build

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030824
(Reporter)

Comment 5

15 years ago
Confirmed in Mozilla 1.5 Beta - Released August 27, 2003
(Reporter)

Updated

15 years ago
Severity: normal → major

Comment 6

15 years ago
Regarding comment #3: The "Send later" action must be interpreted as a send action.

The referenced document states that the message must be removed when hitting
Send later (section "Sending a Draft" subsection E)!!


Additional explanation:

When hitting the Send later button, the user indicates that it has finished
editing the message and that it should be delivered as soon as possible. Hence
there should not be a copy in the Drafts folder, because that suggests that the
message has not been finished and has not been sent. Having a message in the
Drafts folder suggests/indicates that the user has not executed *any* send
action (Send or Send later).

Comment 7

15 years ago
*** Bug 225177 has been marked as a duplicate of this bug. ***

Comment 8

15 years ago
--> IMAP.
Assignee: sspitzer → bienvenu
Component: Networking: MailNews General → Networking: IMAP
(Reporter)

Comment 9

14 years ago
Confirmed in Mozilla 1.7.2 20040803
(Assignee)

Comment 10

14 years ago
I'm debugging this a little bit and I found out that draft messages don't get
ids when they are saved.
http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompose.cpp#3111

// Reset draft (uid) url with the new uid.
if (msgFolder && newUid != nsMsgKey_None)
{
  rv = msgFolder->GenerateMessageURI(newUid, getter_Copies(newDraftIdURL));
  NS_ENSURE_SUCCESS(rv, rv);

  compFields->SetDraftId(newDraftIdURL.get());
}

it fails because newUid == nsMsgKey_None

any ideas why |msgSend->GetMessageKey(&newUid);| returns nsMsgKey_None ?
(Assignee)

Comment 12

14 years ago
David, what would be a correct way to fix this?
(Assignee)

Comment 13

14 years ago
Actually, the patch for bug 80819 caused this problem.

Comment 14

14 years ago
to be honest, I don't know, but I think backing out the relevant part of the fix
for bug 80819 is a definite possibility, since I don't think it was crucial to
that bug. Cc'ing Frank, who did the fix.
(Assignee)

Comment 15

14 years ago
Created attachment 166782 [details] [diff] [review]
fix
Assignee: bienvenu → varga
Status: NEW → ASSIGNED
(Assignee)

Updated

14 years ago
Attachment #166782 - Flags: review?(bienvenu)

Comment 16

14 years ago
Comment on attachment 166782 [details] [diff] [review]
fix

can you use the non-K&R braces style?

do you need PR_FREEIF? PR_Free checks for null, and I don't think you need to
null out msgID, which is what PR_FREEIF does...

static PRBool isEmpty(const char* aString)

the aString style is for idl methods, I thought, though it's preferable here to
the _p thing... :-)
(Assignee)

Comment 17

14 years ago
sorry I forgot to fix the original braces style
the _p thing is really not used anywhere else :)

is this ok?

void nsMsgComposeAndSend::GenerateMessageId()
{
  if (isEmpty(mCompFields->GetMessageId())) {
    if (isEmpty(mCompFields->GetTo()) &&
        isEmpty(mCompFields->GetCc()) &&
        isEmpty(mCompFields->GetBcc()) &&
        !isEmpty(mCompFields->GetNewsgroups())) {
      PRBool generateNewsMessageId = PR_FALSE;
      mUserIdentity->GetBoolAttribute("generate_news_message_id",
&generateNewsMessageId);
      if (!generateNewsMessageId)
        return;
    }

    char* msgID = msg_generate_message_id(mUserIdentity);
    mCompFields->SetMessageId(msgID);
    PR_Free(msgID);
  }
}

Comment 18

14 years ago
sure, as long as you get rid of the k&r braces :-)
(Assignee)

Comment 19

14 years ago
ah, you probably mean
if () {
}

vs

if ()
{
}

I'll fix it before checkin
got your r= ?

Comment 20

14 years ago
Comment on attachment 166782 [details] [diff] [review]
fix

yes, that's right - I prefer 
if (a)
{
  foo();
}
Attachment #166782 - Flags: review?(bienvenu) → review+
(Assignee)

Comment 21

14 years ago
Created attachment 166784 [details] [diff] [review]
final patch
Attachment #166782 - Attachment is obsolete: true
(Assignee)

Updated

14 years ago
Attachment #166784 - Flags: superreview?(mscott)
Attachment #166784 - Flags: review+

Updated

14 years ago
Attachment #166784 - Flags: superreview?(mscott) → superreview+
Product: MailNews → Core
(Assignee)

Comment 22

14 years ago
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Component: Networking: IMAP → ChatZilla
Resolution: --- → FIXED

Updated

14 years ago
Component: ChatZilla → Networking: IMAP

Comment 23

14 years ago
(In reply to comment #3)
> ***This also happens with POP accounts***

Right. BUT I still see this happen on my POP accounts with Mozilla build
2004112405 on WinNT4. I see the summary, so I ask: Was the fix for all accounts
or only for IMAP acc.? If yes, what is with Bug 104818 for the same issue?
(Assignee)

Comment 24

14 years ago
No, it should work right will all accounts.
The other bug might be a different issue.

Comment 25

14 years ago
(In reply to comment #24)
> No, it should work right will all accounts.
As I said it does not. I did the steps from comment 0. My build should have the
patch.

> The other bug might be a different issue.
IMO it is the same, see the steps (compose, save, keep writing, send later).

Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.