User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050501 Firefox/1.0+ Build Identifier: cvs build 20050501 This one just doesn't seem right to me. If I ctrl-E to edit a message, intending to adjust it slightly and send it on to someone else, I find that if I ctrl-S to save the message (as a draft) whilst compsing it, the original message - the one I did ctrl-E on - is deleted. I've only just noticed this, so feel that it hasn't always beahved this way. I can't be the only person to have lost archived emails this way (before I noticed the behaviour), can I? To clarify: I have lots of archived emails. Often, when someone asks me something, I tend to use an archived email as a template. I ctrl-E the message, and adjust it to send to the new person. I often ctrl-S whilst compsing this new message. I've now noticed that this deletes the original and, depending on when this started happening, I've probably lost numbers of old archived emails. Is this behaviour intentional? It seems, to me at least, to be the wrong default, at least. Is there any way to adjust the behaviour? I'm marking this as Major, at least for me: I've lost data thanks to this (or rather my ignorance of it). Apologies for the vague report. Reproducible: Always

this now occurs on mac as well (and so hardware & OS should be modified to all, perhaps) with latest nightly builds where it did not used to as recently as the last release builds, and i agree it is major, because i have also lost data i had kept saved in drafts in this fashion. if one performs "Edit Message as New" *twice*, and then saves both, it's possible to duplicate the old-release behavior, but this seems counter-intuitive to me. the very part of the name "as New" implies to me that the old draft will be left alone. Bug 288062 was submitted and is still unconfirmed as reporting the old behavior ("Edit Message as New" then Save not deleting original message) as a bug that conflicts with double-clicking/hitting-enter-or-return on the message (which i've always interpreted to mean "continue editing original draft"), so the behavior it expects conflicts with the behavior expected by this bug. i think this bug is correct and that bug should be closed.

version 1.0+ (20050616) also me on windows. Can't believe I never noticed it. Also happens with moz suite. add keywords draft and template to summary To reproduce: 1. pick any folder, local or imap 2. click any message 3. ctrl-E or alt-M and edit message as new 4. ctrl-D or file|save as|File (or template) Results: original message is gone Expected results: original message not touched

the problem even occurs when the old message is still open in a compose window: 1] compose mail 2] save (causes item to be saved in Drafts folder) 3] go to saved item in drafts folder 4] Cmd-E on mac (presumably Ctrl-E on windows) to "Edit Message as New" 5] a second compose window is opened 6] (optional) change message, particularly subject line 7] save notice that in the drafts folder, the originally saved message is no longer there. one can go to the original message window and hit save again, and the message will then be saved as a second window (this is the workaround i have come up for for this bug) this did not occur in the last release build, only in the recent nightly builds. (i've been using a subfolder of drafts to keep "diary"-style logs on a daily basis, so i've been doing this for a year; it's only recently that this problem has surfaced). can someone please look at this, up the level to critical (because of the data loss aspect and the fact that this did not used to occur), and mark the status as confirmed before it goes into a release sometime soon?

I believe that the important distinction is whether or not the "original" is in the (or a) Drafts folder. If it is, then possibly one might argue that continuing to edit it, and saving, ought to result in the original's deletion. But only for something in a Draft folder, surely, not a random non-Draft folder?

Just to emphasize: the bug I logged here is explicitly *not* about (original) mails in a Drafts folder, but mails in a general, non-Draft folder. I need to re-state this, since there may be a belief that it's ok to delete an original in the Drafts folder, and I don't want this bug side-tracked by that discussion.

i believe it is *not* an important distinction about whether or not it is in a drafts folder or sub-folder or not. even for drafts, if the user performs "Edit Message as New", the original should remain untouched, regardless of its location. that's why the command is called "Edit Message as New". "as New" being the key distinction. for drafts, there's already the "Edit Draft" button to allow you to continue editing the same draft, and the same functionality occurs if you double click the message from the pane containing the subject/recipient/date/etc info of all the messages. again, this must have been a very recent change. the sooner this bug is looked into, the easier it will be to backtrack and find the code that was changed and back it out. the longer this bug is left without being looked into, the harder this will be. and i'd like to emphasize as the original reporter stated that this bug will result in loss of data if the user is not aware of the bug being there.

I'm still seeing this serious bug in Thunderbird version 1.0+ (20050719) (win)

also still seeing this in version 1.0+ (20050722) on mac. also noticing that my attempt at a workaround (creating a message in Templates) fails because once i use the template one time, the template disappears!!!! this is a recent major bug, causes data loss, and shouldn't be that hard to track down and revert. can someone with authority please look into this? i notice nightly builds are already being marked alpha 2. there's no way a release should be made with a bug this major.

Shouldn't this "major" dataloss bug have a Blocking Flag and/or a Target Milestone? I have often lost important documents due to this bug, and I don't think Thunderbird 1.5 should be released with this bug.

working on a fix.

only remove original message if it was a draft or template. This isn't perfect, since in theory when you do a edit message as new in the drafts or templates folder, you should get a new message, but we don't have a compType that enables us to distinguish between edit draft/template and edit message as new.

(In reply to comment #11) > only remove original message if it was a draft or template. This isn't perfect, > since in theory when you do a edit message as new in the drafts or templates > folder, you should get a new message, but we don't have a compType that enables > us to distinguish between edit draft/template and edit message as new. Note that this works perfectly with Mozilla 1.7.11. Edit as new from a draft msg and saving creates a NEW msg in Drafts. Perhaps Bug 288702 caused this?

(In reply to comment #12) > Perhaps Bug 288702 caused this? See bug 308037 comment 2.

(In reply to comment #11) > only remove original message if it was a draft or template. This isn't perfect, > since in theory when you do a edit message as new in the drafts or templates > folder, you should get a new message, but we don't have a compType that enables > us to distinguish between edit draft/template and edit message as new. Neither Drafts, nor (especially) Templates should be deleted when editing as *new*. I can understand the desire to get a "quick fix", but this bug is *still a bug* with this partial fix. How hard would it be to add a "compType that enables us to distinguish between edit draft/template and edit message as new"? That would be a complete and correct fix. Reopen? New bug? PS. ostgote: What was the purpose of changing the "+" flag back to a "?" flag?

putting the plus back.

(In reply to comment #14) > PS. ostgote: What was the purpose of changing the "+" flag back to a "?" flag? No purpose, I did not want this, it happened accidentally (scroll mouse?). Sorry.

(In reply to comment #14) > Reopen? New bug? I've filed Bug 321355 for the remaining issue: Edit a draft message as new and saving this mail overwrites/deletes the original/previous one ("Edit As New"/Ctrl+E)

(In reply to David :Bienvenu from comment #11) > Created attachment 195749 [details] [diff] [review] > proposed fix > > only remove original message if it was a draft or template. This isn't > perfect, It was actually very wrong design... > since in theory when you do a edit message as new in the drafts or templates > folder, you should get a new message, In practice, too! > but we don't have a compType that enables > us to distinguish between edit draft/template and edit message as new. (In reply to Peter Lairo from comment #14) > Neither Drafts, nor (especially) Templates should be deleted when editing as > *new*. I can understand the desire to get a "quick fix", but this bug is > *still a bug* with this partial fix. Indeed! This was fixed by Bug 321355, but much of the problem (introduced by bug 288702 I think) where "Edit as New Message" was conflated with "Edit draft"/"Edit template" has still survived to this day, especially the UX nightmare of bug 78794 (which will be fixed by our current plans for bug 731688, WIP). Bug 1106412 introduced "Edit draft" command. Bug 1389062 will introduce "Edit Template" command (the wrong "workaround" for which, "Edit as New Message", then save as template, probably disappeared with bug 321355). > How hard would it be to add a "compType that enables us to distinguish > between > edit draft/template and edit message as new"? That would be a complete and > correct fix. It's truly unfortunate, Peter Lairo, that your spot-on advice was not heard at the time when you offered it. More than a decade later, we're now in the process of fixing that structural problem by introducing that missing compType in bug 731688, attachment 8895053 [details] [diff] [review]: > Components.interfaces.nsIMsgCompType.EditAsNew Having said which, compose pipe is so deeply nested that it's understandable that nobody has been willing to touch it... And David Bienvenu (assignee here), one of two lead developers at the time when this occured (2005), left the project in 2007. Anyway, good things come to those who wait! We're trying to sort this out properly, once and for all. Here's the big plan: (In reply to Thomas D. from bug 78794 comment 74) > 1) Bug 731688: Change 'Edit as New Message' to observe *account* format > preference (ux-consistency with reply, forward etc.; fix bug 78794) > 2) Bug 731688: Improve 'Edit as New Message' to allow Shift modifier for > opposite *account* preference (ux-consistency) > > 3) Bug 1389083: Implement 'New Message from Template'; observe *message* > format and Shift modifier for *opposite* of message format. This eliminates > the current wrong conflation where "Edit as New Message" acts as "New > Message from Template". > 4) Bug 1389062: Implement 'Edit Template' (ux-efficiency); observe *message* > format and Shift modifier for *opposite* of message format.