151361 - First mail in new account will be saved in two mails

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[Christian Eyrich]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1a) Gecko/20020610
BuildID:    2002061204

Saving (CTRL-S) the first mail one writes on a new account will be saved in two
mails. The first on holds the first state, subsequent save actions will go to
the second one.

Reproducable in 1.1a builds 2002061014 on Linux and 2002061204 on Win95.

Reproducible: Always
Steps to Reproduce:
1. Create new mail account
2. Click compose and type anything
3. Press CTRL-S
4. Type anything
5. Press CTRL-S

Actual Results:  Mail will be saved in two different mails.

Expected Results:  Mail should be saved in only one mail.

Comment 1

[David :Bienvenu]

are you using local/pop mail or imap?

Comment 2

[Christian Eyrich]

I'm using pop mail.
Reading through my description I see I forgot something. To clarify, the mails
I'm writing of are written to Drafts because of saving them while composing. So
it should be irrelevant which protocols/severs used.

Comment 3

[David :Bienvenu]

drafts can be online (imap) or local. So which protocol can and does matter.

Comment 4

[Christian Eyrich]

Ok, every day something new to learn - sorry.
So: everything is offline resp. pop/smtp.

Comment 5

[Christian Eyrich]

Attachment: Proposed patch

Normally the draft gets invalidated (flag set in X-Mozilla-Status) when saving
a newer version to Drafts.
This didn't work for Drafts that where the first in the file on disk, that
means either the first on a account ever saved or the first after an "empty"
Drafts folder has been compacted. But only if the second save action was
performed without leave and new open the draft then.

That's because nsMsgComposeSendListener::RemoveCurrentDraftMessage called after
the save, gets and saves the offset of the now current message. In case of the
first in file this offset ist 0. But before using the variable newUid
containing this offset it has been tested if != 0 ...

I now removed this test - that's all.
Since the rv of the function getting the value is tested it's sure enough I
think.

Comment 6

[David :Bienvenu]

Comment on attachment 118990 [details] [diff] [review]
Proposed patch

it should probably be testing for newUid != nsMsgKey_None, since that's  the
invalid uid, not 0, as you point out.

Comment 7

[Christian Eyrich]

Attachment: new patch, changed newUid test

You're right, better double-check it.
I didn't know nsMsgKey_None - added this test now.

Comment 8

[David :Bienvenu]

Comment on attachment 119011 [details] [diff] [review]
new patch, changed newUid test

r/sr =bienvenu, thx.

Comment 9

[David :Bienvenu]

fix checked in. Re-assigning to Christian first.

Comment 10

[David :Bienvenu]

marking fixed.