Sheela Ravindran Reporter
	Description • 23 years ago

branch build: 2001-09-07-06 
I noticed this while running basic functional on the above branch build.  When 
you edit an existing message or saved message in drafts or templates the message 
moves from the local draft/template folder to the imap template/draft folder.

steps:
-create a new profile with imap as 1st account and pop as second account
-Make sure the 1st account imap copies and folders for drafts and templates 
points to the drafts/templates on that imap account.
-Change the copies and folders of the 2nd account to place the saved 
draft/template message to local folder draft/template respectively.
-compose a new message from the 2nd account
-save as draft (file|save as |draft, or toolbar button save)
-You will see the message in the local folder drafts
-select this message 
-click on the edit draft button
-make changes to this message
-save again

Actual: The changes are saved and the message from the local folder is moved to 
the first account imap drafts folder.

Expected: The changes are saved to the existing message and that it still 
resides in the drafts local folder

This behavior is also seen when doing the same with templates.

	Sheela Ravindran Reporter
	Comment 1 • 23 years ago

Adding keywords and nominating this bug for emojo.  

	Scott MacGregor
	Comment 2 • 23 years ago

this sounds kind of nasty. Not sure I would stop ship eMojo for it though.
nsBranch- now but sending to Cavin for investigation. If he thinks the fix looks
easy we'll move this to nsBranch+ status.

	Håkan Waara
	Comment 3 • 23 years ago

Was this supposed to be reassigned to Cavin as well?

	Cavin Song
	Comment 4 • 23 years ago

I was able to reproduce the problem using the 6.1 RTM build (20010726) as well 
so I guess the problem has been there for a while. I didn't have to follow 
the exact steps as described by Sheela to reproduce the problem, however, and 
here is what I did:

1. Set up two accounts and folder settings exactly like Sheela described (ie, 
one IMAP and one POP3).
2. Then I opened the Drafts folder under account Local Folders (ie, neither IMAP 
nor POP3 account) and launched a new compose window. At this point the Drafts 
folder had no msgs (since I just created a new profile so everything was empty).
3. Typed in something in the compose window and hit Save. Still no msgs showed 
up in the Drafts folder I just opened (it should if the program worked).
4. Opened the Drafts folder associated with the IMAP account and the draft msg I 
just saved showed up there!

From here on, every time I hit the Save button in the compose window the new 
(draft) msgs were saved to the Drafts folder associated with the IMAP account 
and the one under Local Folders showed no msgs at all.

So my guess is that we did not associate the right folder or account info with 
the compose window launched from the Local Folders account because looks like it 
always points to other account's set folder (in this case, it's the 1st 
IMAP account I created).

I'm going to start debugging the problem now. JF, if you have any idea about 
this please let me know.

	Cavin Song
	Comment 5 • 23 years ago

After looking this further more I realized that Local Folders account does not 
even have settings for Sent, Drafts and Templates folders and maybe that's why 
it's linked to those defined in the 1st account (ie, id1). In other words, when 
you save a draft msg under Local Folders account, where would you put the msg 
given the fact that no Drafts folder is defined for Local Folders? 

So I think this works as designed but I need JF or someone to confirm that.

In summary, if you:

1. Launch a compose window from Local Folders and save it (as draft), or
2. Launch a msg from the Drafts folder under Local Folders, edit it and save it.

then the new draft msgs are saved to the Drafts folder defined in the 1st 
account. You can reproduce this by only having a single IMAP account in a 
profile.

	Scott MacGregor
	Comment 6 • 23 years ago

Pushing out in light of cavin's research. 

	Sheela Ravindran Reporter
	Comment 7 • 23 years ago

Jennifer,
Can you comment if the above described behavior is how it should work.  I did
refer to the specs but was not able to conclude anything for this scenario.  
But the way it appears right now it looks like the message just disappeared from
the local draft folder after editing.  I did a search for messages and happen to
find it in imap draft folder. This could a little bit confusing to the users if
they run into it.  

	Sheela Ravindran Reporter
	Comment 8 • 23 years ago

I understand from cavin that this has been there always. I removing the
regression keyword. 

	laurel
	Comment 9 • 23 years ago

We have an older bug about this kind of problem (lack of Identity involved with
Local Folders), particularly it was reported for Unsent Messages (since they're
stored in Local Folders) and multiple accounts -- that the identity on sending
unsent messages will change to the default account. Just FYI, for reference -
bug 59548

	jglick
	Comment 10 • 23 years ago

Sheela says in the original description of the bug that she edited a 
Draft/Template already saved in the Local Draft/Template folder and when 
she saved it, it was Not saved to its current location, but instead, 
disappeared from its current location and was instead saved to the IMAP 
Draft/Template folder. This seems like the wrong behavior. Updating and 
saving an existing Draft/Template shouldn't move it, but replace the existing 
message in the existing location.

	Asa Dotzler [:asa]
	Comment 11 • 23 years ago

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

	Sheela Ravindran Reporter
	Comment 12 • 23 years ago

This bug still exists.  2001-12-14-06 win98

	Jean-Francois Ducarroz Assignee
	Comment 13 • 23 years ago

The solution would be to save the identity key with the message, at least when
it's saved locally. Edit message would have to read it ans setup the identity
correctly.

	Frank Schönheit
	Comment 14 • 22 years ago

Jean-Francois, how would you suggest should this saving be done? Add a new
internal header line when saving as draft and removing it upon editing?

	Jean-Francois Ducarroz Assignee
	Comment 15 • 22 years ago

correct, we already do that for other needed info...

	Frank Schönheit
	Comment 16 • 22 years ago

The attached patch fixes the original problem described by Sheela:

When saving a file as draft or template, an additional header is stored (named
"X-Mozilla-Identity-Key" - better suggestions welcome :), which denotes the key
of the identity which was used to compose the message.

When opening a draft or template, this header is evaluated, and the respective
identity is retrieved and used to initialize the mail composer.

Not sure if I missed something or if the patch really solves the problem
completely, but it works fine for all scenarios I tried (amongst them the
original one described by Sheela).

What is not solved by this pice of code is the problem Cavin described in
comment 5, point 2.: As there is no identity associated with "Local Folders",
and the mail composer seems to need an identity where it retrieves the target
folder for saving a draft/template, this sounds not that easy ....

	Jean-Francois Ducarroz Assignee
	Comment 17 • 22 years ago

good patch. But we already have code to save the identity key when queuing a
message (send later). All you have to do is to use HEADER_X_MOZILLA_IDENTITY_KEY
and write out this header when saving a draft/template as well...

	Frank Schönheit
	Comment 18 • 22 years ago

oh, missed that ... thanks!
What's the difference between mime_generate_headers (where I hooked in) and
nsMsgComposeAndSend::MimeDoFCC (where HEADER_X_MOZILLA_IDENTITY_KEY is
generated)? Should I prefer one of these locations? From the name, I would
expect that writing the header fits better into mime_generate_headers ...

	Jean-Francois Ducarroz Assignee
	Comment 19 • 22 years ago

mime_generate_headers seems a better place for doing that. But if the code is
alreay in doFCC (the code that copy the message into a folder), please do the
same. I thing the historical reason is that maybe, you don't have access to the
identity in mime_generate_headers.

	Frank Schönheit
	Comment 20 • 22 years ago

using the HEADER_X_MOZILLA_IDENTITY_KEY header makes the patch _much_ smaller
indeed :)

	Jean-Francois Ducarroz Assignee
	Comment 21 • 22 years ago

Comment on attachment 105223 [details] [diff] [review]
revised version using the HEADER_X_MOZILLA_IDENTITY_KEY header

Looks great. Good job. R=ducarroz

	David :Bienvenu
	Comment 22 • 22 years ago

don't we have to free identityKey? Or use an nsXPIDLCString?

	Jean-Francois Ducarroz Assignee
	Comment 23 • 22 years ago

correct, we need to free identityKey

	Frank Schönheit
	Comment 24 • 22 years ago

oops .... overlooked this leak :( Thanks!

	Jean-Francois Ducarroz Assignee
	Comment 25 • 22 years ago

Comment on attachment 105234 [details] [diff] [review]
revised version, one less memory leak ...

not good, the PR_FREEIF should go outside the if block (in case identityKey is
not null but an empty string)! Also, don't need to use the PR_FREEIF macro
here, instead use PR_Free even if identityKey is null

	Frank Schönheit
	Comment 26 • 22 years ago

freed identityKey correctly this time (I hope :)
(no more patches from my side today, they cause too much disgrace at 11pm)

	David :Bienvenu
	Comment 27 • 22 years ago

Comment on attachment 105242 [details] [diff] [review]
corrected the correction

thx, sr=bienvenu, as long as it's OK with JF.

	Jean-Francois Ducarroz Assignee
	Comment 28 • 22 years ago

Comment on attachment 105242 [details] [diff] [review]
corrected the correction

Viel besser. R=ducarroz
Gute Nacht Frank :-)

	Jean-Francois Ducarroz Assignee
	Comment 29 • 22 years ago

Comment on attachment 105242 [details] [diff] [review]
corrected the correction

per bienvenu's comment, SR=bienvenu

	Jean-Francois Ducarroz Assignee
	Comment 30 • 22 years ago

Fix checked in the trunk. Thanks Frank for the patch.