User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10 StumbleUpon/1.998 Build Identifier: Thunderbird version 0.8 (20040913) When you move a draft message into subfolders of the "Drafts" folder and then edit the draft message and then save it, it moves back into the "Drafts" folder rather than staying where you put it. For people who work on many different draft messages at the same time, being able to organize them into subfolders is very important. Having the draft messages move back into the main "Drafts" folder disrupts this organization. Reproducible: Always Steps to Reproduce: 1. Create a new message. 2. Save the message as a draft. 3. Create a subfolder under the "Drafts" folder. 4. Move the draft message into the subfolder. 5. Edit the draft message. 6. Save it. Actual Results: The draft message is back under "Drafts". Expected Results: The draft message should be put back where it was found, in the subfolder of "Drafts".

meant to request that this bug also be listed for MacOS X (meaning perhaps it should be changed to be listed for all).

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

still a bug, please do not auto-resolve. i will come back every few weeks and say "still broken" as necessary, because this is constantly a problem for me, as i make heavy use of draft subfolders.

I can confirm this to be a bug. Thunderbird version: 2.0.0.14 (20080421) OS: Windows 2000

I also can confirm that the bug still occurs in TB 2.0.0.14. Note that if you move a message to to a subfolder of drafts it will have a "Edit Draft" button available when selected. If you move the message out of of the draft folder tree, the button is no longer shown. This seems to indicate the original programmers thought of the subfolders of the draft folder as being similar in nature to the drafts folder. Here is why I think that this both is important and is a bug (not a design feature). Right now, you can create subfolders under the drafts folder. Now, what is a user to make of this ability? You can create subfolders in many different locations. You can save emails related to one project in one folder, emails related to some mailing list in another folder, emails from a friend in another folder, etc. Why create a subfolder of the drafts folder? Seems pointless except for one purpose - to organize drafts. For myself, every month I send out multiple sets of emails to multiple organizations. Being able to create subfolders of drafts and store different sets of emails in different subfolders is extremely useful, or would be if it really worked. The problem is that if you move a draft message into a subfolder of the draft folder and then edit it, when you save the message it goes right back into the main draft folder, rendering the draft subfolders useless. Other than to organize drafts, I can think of no reasonable reason for allowing the existence of subfolders of the drafts folder. If anyone can think of another reason, please enlighten us. This means that the current behavior surprises and annoys users. I contend that if you decide to create subfolders of drafts, you certainly do not want or expect messages you move there to be moved back to the main draft folder. Now, I realize that not all users will be surprised and annoyed. Certainly those users you never have a need to organize draft messages and who never attempt to use subfolders of draft will not be surprised and annoyed. Allowing the user to create subfolders of drafts creates the expectation that those subfolders will be useful. I do *not* see the subfolders of drafts being a way to save personal notes. Logically, those would be stored under a "Notes" folder, not a "Drafts" folder. personally, I just send myself an email when I want to write a note to myself. Wastes a minuscule amount of bandwidth, but compared to the volume of spam I receive every day it's trivial. I have tried the [Drafts and Templates] options and that really doesn't do the trick. That allows you to change which folder all drafts are stored in but does not allow you to organize drafts.

3.0a1 is done already.

(In reply to comment #7) > 3.0a1 is done already. You are correct. I did not realize that at the time I flagged this bug. However, there is still a question of whether or not this is Bugzilla entry is a bug or a request for enhancement. Myself and Jamie Nettles believe it to be a bug; several other people (Rod Whiteley, Brian Kennelly, possibly ovidiu as well) argue that the current behavior is correct and this entry is a request for enhancement. I would like to reach some agreement on this topic.

is bug 327854 a dupe? (someone else suggested)

(In reply to comment #9) > is bug 327854 a dupe? (someone else suggested) > Not so sure. They are very much related considering the drafts UI confusing aspect. But this one is about having drafts in subfolders of draft, as the expected/unexpected behavior (or other folders ), while that one regards the identity vs account + drafts behavior. [Which is not really inaccurate as it works today. More there ..] I would consider same if both issues are treated together. Like moving that acc/ident here. Or maybe better falling under the same "drafts meta".. Like "rethink drafts logic vs UI" -cause that's the thing that makes them related. As about comment 8: -I do not consider bug the way happens today as this is not really an error. It's more about the inner logic of the drafting (that results in the UI issues) that can be changed/improved. In that respect would be enhancement -I could agree to consider a (minor?) bug only the UI aspect, expectations vs behavior. I do consider the lack of documentation and guidance part of the ui confusion, by not presenting the drafts logic to the end user. So, I would leave it enhancement, cause the change of inner logic may just be you actual target. (would that make it core instead of front end? no, probably front end would just generate some core stuff, but for now, front end has to be treated ..)

as a voter for this bug, i obviously disagree vehemently with comment #10 that this is not a bug. the logic of comment #6 seems very clear as to why this should be a "bug" and not an enhancement: the subfolders of "drafts" have an "edit drafts" button, and it is counter-intuitive to hit such a button and find the saved result in a different folder. further, while it has been quite a while (this bug has existed for 3 1/2 years and still bothers me, because i use the drafts folder in a fashion similar to that described in comment #6) ... it is my memory that prior to the submission of this bug, it used to be the case that drafts in subfolders that were edited did NOT get moved back to the drafts folder. as this was previous behavior, it seems like a bug. please re-consider changing this back to a "bug" and not an "enhancement".

Ok, I agree the "edit draft" button shows that UI here is rather negligent and indirectly that (probably) the so called inner logic was not digested really, ending up in confusing and misguiding elements. With all comments here and in bug 432348 it is a problem and not only a rfe. Meaning that _I will confirm this as new_, and even make it bug if that's what it take to be addressed, cause there is a fault there. Also present in other bugs or requests (BTW, tb3 is same ..) Now, I don't want to dissect this too much. Assuming this bug means "let the subfolders and button there and just add the functionality underneath", you can consider it bug, but not like removing buttons is going to solve it. As I said before, the UI issue is buggish, while the enhancement is rather about inner logic. Now, this being a bug or enh, I too consider it necessary to be cleared and fixed in both aspects 1.consistent, intuitive element/function presentation (buttons or folders to behave as expected or not allow them ..) 2.consider (the very logic of) having organizing abilities for drafts and drafts folder note: I would (and probably will) consider a folder pane (vs account manager?) meta to gather the various folder bugs (drafts, junk, unsend, saved searches, UI tweaks etc) so that they get trated together when working on this area. Some may need to go into acc manager too.

Can we get this bug fixed ?! It was reported in excellent detail back in 2004 by the OP and it is an ongoing issue.

I always thought there was only one folder where drafts could be saved, i.e. drafts. Are subfolders of drafts marked special?

yeah, they're considered to have the drafts flag set, like sub-folders of the sent folder are considered to have the sent flag set...

For future direction I think the better tagging interface is going to handle this core problem of organization better. Things ( http://www.culturedcode.com/things/ ) is an example of a fairly common tag filtering interface available in many applications today. The tagging interface allows for organization by filtering away items not tagged with the selected tags. I'm hopeful we can have an interface of this sort for tb3. A major benefit that tagging your drafts to organize them is that tags can persist even after the message is sent. Unlike sub-folders where that organizational information is lost once the message is sent a tag will persist (within Thunderbird) as the message is moved to sent and will be shown if replies to the message are received. As for a short term direction I'm not really clear how best to proceed.

(In reply to comment #17) > As for a short term direction I'm not really clear how best to proceed. I would like to nominate that we implement the proposed solution from the original bug report: "The draft message should be put back where it was found, in the subfolder of 'Drafts'." Tagging would be a nice feature to have, but this bug report is concerned with a relatively simple problem, and proposes a relatively simple solution. To make this into a discussion of whether to implement tagging takes us away from the original intent of this bug report.

Anyone ever read "The Psychology of Everyday Things" by Donald Norman? Norman explains that when we go to use a device, we have in mind a model of how the device works that may or may not correspond to the model of the device that the designer of the device had in mind. A device has "affordances", that suggest how the device is used. For example, one door may have a handle that suggests the door is pulled while another door has a handle that suggests the door is pushed. If we come upon a door with a handle that suggests pull when in reality the door should be pushed, we are annoyed. Right now, Thunderbird has an affordance that suggests that drafts can be stored and edited in subfolders, but it turns out this is not true. The model in the user's mind (suggested by the interface) does not match the model in the developers mind. We could arrogantly insist that the developer is right and the user is wrong, but do we really want to **** off the user? Don't we want to see Thunderbird the most celebrated and popular email client in existence? Right now, it seems that when the routine that writes out a draft message looks for a folder to write it to, it looks up the name in some global location. What would have to change is that at the start of editing of an existing draft message, the current location of the draft message would have to be remembered locally. Then when the draft message was being written out, if it was a new draft message, things would proceed as before. If it was an old draft message, it would be written to the old, remembered location. Famous last words, I know, but it doesn't sound too hard for someone familiar with the code, unless there are lots of levels of abstraction between the reading and writing of the existing draft message.

i agree with comment #18, and to augment comment #19 with agreement, you can see that i've stated in previous comments that i believe that this is a regression ... i.e. that it is my recollection that this worked as the original submitter wants it to work at a time prior to his original submission, and that some change at some point along the way caused the behavior to break. thus it could be argued that the developer in this case wasn't even right, and that the original design is in agreement with the "affordances" that are suggested in the UI. (certainly, fixing a regression shortly after it is introduced is a lot easier than the forensics required to discover what caused the "regression" 4 years after the fact.)

> (certainly, fixing a regression shortly after it is introduced is a lot easier > than the forensics required to discover what caused the "regression" 4 years > after the fact.) This is a good point, though perhaps not for what you are arguing. If this feature hasn't been working for more than 4 years I wonder if it is best to fix it now vs. examining if the affordances mentioned will still be present. Several things have changed related to the drafts folder for TB3. The new folder pane (bug 446306) will offer a drafts mailbox instead of a regular folder. The draft mailbox displays the collection of draft messages from any user account. The expansion of the mailbox displays separate accounts where each draft message is located. gloda (bug 450494) provides message tagging that's planned to be used for tagging any message Thunderbird sees. What remains to be done (and doesn't seem to have a bug yet) is the tag filtering interface.

Still an issue in 3.0.1 on Mac OS X Like others, I use Drafts as a way to maintain information that I can access from any IMAP client. My creation of Drafts has nothing to do with sending an email, it's more a note to myself. I currently have 52 Drafts that I recently organized into 5 subfolders. I was very surprised to find that editing an email puts it back into the Drafts folder. Worse, autosave creates many copies of it so, after a few hours of editing, I'll have dozens of copies in my Drafts folder. Very annoying!

Wayne Mery (vn) <vseerror@Lehigh.EDU> wrote me: Hi Kent. it would be very helpful if you could get a log of the protocol activity while this happens. please use the instructions at https://wiki.mozilla.org/MailNews:Logging to get ImapAutoSync:5,imap:5,imapoffline:5,timestamp and attach log file to the bug. thanks

Notes for the attachment: 1. turned off all folder synching 2. modified auto-save to 1 minute 3. started by editing a mail in a Drafts subfolder called "Computer Stuff" 4. the mail's subject line was "Tiger DomU Stuff" 5. immediately "saved" the email a witnessed it showing up in the Drafts folder (not the subfolder it came from) 6. then edited the file, but did not save the edits 7. then started editing a new mail with subject line "test new file" 8. saved the new email right away and then edited it some more without saving 9. waited about a minute 10. saw a new (2nd copy) of my "Tiger DomU Stuff" email in the "Drafts" folder - one has timestamp 7:37 - the other shows 7:41 - I'm in EST (i.e. UTC -5:00) 11. immediately quit the app (saving both emails in the processed) 12. Ctrl-C the process and attached the log file Thanks!

* Clearly a bug (best experienced with pop3-account and view > folders > all) * datalossy and highly confusing (user can easily end up with multiple different copies of same mail in different draft folders) * and a true shame for TB since I'd really expect such basic functionality to work. Still present in current Trunk, 10.0a1 2011-10-31.

Testsuite/Litmus flags are typically only used when a patch lands.

omg! FTR: For users organizing their drafts in subfolders (esp. corporate users), this bug constitutes a grossly confusing violation of several ux-principles. They end up with multiple versions of the same draft in different folders. If the user doesn't realize the behaviour of this bug, more errors will occur as a result of this (datalossy). I wonder if editing and saving a draft could be basic enough a usecase that developers might consider fixing this.

Hi, I started to investigate this bug that's very disturbing for me : - created a VM in virtualbox - downloaded sources from mercurial - compiled in debug mode (just needed to change 2 lines in the default mozconfig to handle default path for build tools) - from source I traced the code from the click in "Save Draft" button to nsMsgCopy::StartCopyOperation() I suppose that this method should be modified to test if the message is already in a draft subfolder and adapt the future save folder. But I have some problems to do this test : - the param aMsgSendObj is a nsIMsgSend and his field 'm_folderName' is std : "xxx/Draft" - the param aMsgSendObj seems to be a incomplete copy of the original nsMsgCompose (only headers, content, attachments seems copied) - with bug 349547, if found that we can get the uri from the curent window : we can use the gMsgCompose that is a nsMsgCompose - just like bug 349547, I would like to access 'w.document.defaultView.gMsgCompose.compFields.draftId' of the current window from nsMsgCopy::StartCopyOperation() - I started with aMsgSendObj->mParentWindow but needed complicated casting, so I thought it was the wrong way to get the draftId and here are my questions : - is this the right way to solve this bug ? - is nsMsgCopy::StartCopyOperation() the right method to modify ? - how can I get the original uri or draftId of the message from 'aMsgSendObj' ? thanks, Michel PS : i already worked on bugs 349547 and 739311 (js only), and this is my first work in Cpp for Thunderbird

Can't you just get the folder from aMsgToReplace.folder and check that using isSpecialFolder?

Hi, thanks for working on this. (In reply to michelr from comment #28) > - from source I traced the code from the click in "Save Draft" button to > nsMsgCopy::StartCopyOperation() That looks like the right place to start with. > I suppose that this method should be modified to test if the message is > already in a draft subfolder and adapt the future save folder. Yep, I agree. > But I have some problems to do this test : > - the param aMsgSendObj is a nsIMsgSend and his field 'm_folderName' is std > : "xxx/Draft" Have you tried looking at the aMsgToReplace parameter (nsIMsgDBHdr)? I think if you're saving this message as draft, then you can check the parameter is non-null, if it is non-null, then you can get the folder attribute (http://hg.mozilla.org/comm-central/annotate/3debe9b1eed2/mailnews/base/public/nsIMsgHdr.idl#l98) - rv = aMsgToReplace->GetFolder(...) etc. The folder attribute should be pointing at the folder that the original message was in (as it is the message to replace), and so you should then be able to store that value in dstFolder, rather than the value obtained by GetDraftsFolder. Feel free to ping me if you need more help.

My problem is exactly as described by O.P. & Kent above. System: WinXP+SP3 & Thunderbird 17.0

Per my comment 27, I still consider this a dataloss(y) failure for a very basic scenario which should be fixed, irrespective of how many users might be affected or not. Imagine your favorite word processor randomly moving your documents to some other central folder just because you opened it from some other less popular folder. Jorg, comment 29 / comment 30 seem to have a pretty clear idea how to fix this. Wanna try?

Not right now. Personally I think that using subfolders in the drafts folder is pretty, well, unusual, not to use a stronger word. More worth fixing would be bug 321355.