263114 - Saving draft message opened from Drafts *subfolder* unexpectedly creates a new copy of the draft in main Drafts folder, resulting in multiple versions and gross error-prone ux-confusion

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Jamie Nettles]

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".

Comment 1

[xolaware.llc]

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

Comment 2

[Gervase Markham [:gerv]]

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/

Comment 3

[xolaware.llc]

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.

Comment 4

[checkit]

I can confirm this to be a bug.

Thunderbird version: 2.0.0.14 (20080421)
OS: Windows 2000

Comment 6

[Jamie Nettles]

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.

Comment 7

[Magnus Melin [:mkmelin]]

3.0a1 is done already.

Comment 8

[checkit]

(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.

Comment 9

[Wayne Mery (:wsmwk)]

is bug 327854 a dupe?  (someone else suggested)

Comment 10

[ovidiu]

(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 ..)

Comment 11

[xolaware.llc]

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".

Comment 12

[ovidiu]

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.

Comment 14

[Patrick Rynhart]

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

Comment 15

[Wayne Mery (:wsmwk)]

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

Comment 16

[David :Bienvenu]

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...

Comment 17

[Bryan Clark (DevTools PM) [:clarkbw]]

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.

Comment 18

[checkit]

(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.

Comment 19

[Jamie Nettles]

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.

Comment 20

[xolaware.llc]

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.)

Comment 21

[Bryan Clark (DevTools PM) [:clarkbw]]

> (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.

Comment 22

[kent]

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!

Comment 23

[kent]

Attachment: trace with ImapAutoSync:5,imap:5,imapoffline:5,timestamp

Wayne Mery (vn) <[e-mail]> 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

Comment 24

[kent]

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!

Comment 25

[Thomas D. (:thomas8)]

* 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.

Comment 26

[Mark Banner (:standard8)]

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

Comment 27

[Thomas D. (:thomas8)]

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.

Comment 28

[michelr]

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

Comment 29

[Magnus Melin [:mkmelin]]

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

Comment 30

[Mark Banner (:standard8)]

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.

Comment 31

[John Yeadon]

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

Comment 32

[Thomas D. (:thomas8)]

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?

Comment 33

[Jorg K (CEST = GMT+2)]

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.

Comment 34

[Wayne Mery (:wsmwk)]

not dataloss - it's just in the wrong place

Comment 36

[klorgfasder]

I have a lot of drafts for many ongoing projects. To be forced to organize them in a single folder (using subject or tags) is very inconvenient, to say the least. I'd really appreciate to have the option to organize drafts as drafts in subfolders.

The current UI (102.6.0) is indeed misleading, too: A right click on a message in a subfolder of Drafts says "Edit Draft" but actually creates a new message (as if clicked "Edit as new") in drafts top folder - which is more a "template" functionality.

Comment 37

[Jonathan Kamens]

Absolutely astounding that this isn't fixed after 19 years.

This is ABSOLUTELY a data-corruption issue. If you work on drafts over time and use subfolders then this is inevitably at some point going to lead you to making changes to a draft and then later going back and making changes to a different draft thinking it's the most recent copy, with the end result that what's in the draft is not what you expect. And it's a data-loss issue in that if you do all that and then end up sending a draft without all of your changes in it those missing changes are effectively lost.

As for the people who made snarky comments above about it being "unusual" to keep drafts in subfolders, (a) storing scheduled drafts is the most common request I get for Send Later, and (b) many Send Later users have made it clear that they have literally hundreds of drafts at any given time, making it entirely understandable why they might want to organize them in subfolders. I think the TB devs here need to spend a bit of time trying to imagine how users of TB might use it differently than they do.

If TB is going to treat subfolders of Drafts folders as Drafts folders themselves, then it needs to handle this properly. To be clear, fixing this is the right answer, NOT preventing drafts folders from having subfolders that are also drafts folders. This is clearly a feature that users want and need, and it should be fully and properly supported, not gotten rid of.

Comment 38

[Jonathan Kamens]

Sorry, to clarify a typo in my last comment: storing scheduled drafts in a different folder is the most common request I get for Send Later.

Comment 39

[Wayne Mery (:wsmwk)]

The question I would pose, which I'm not sure has been raised so far, is whether there is an RFC (spec) which requires, supports or allows for what is requested in this bug.

Comment 40

[Jonathan Kamens]

I don't understand what you're asking here.

Do you mean, like an Internet RFC from the IETF? I can't imagine that's what you mean, because how Thunderbird chooses to manage folders has nothing to do with Internet RFC's, but that's the meaning I can most readily map to the acronym.

If you're asking whether this is somehow linked in to what is permitted by the IMAP protocol, then (a) I would mention that Thunderbird does note just support IMAP, (b) even if IMAP needed to treat this specially it could still be permitted in Local Folders, (c) in any case, RFC 6154 does not preclude multiple folders from being marked as drafts folders, and (d) the IMAP protocol standards do not actually require any particular folder to be designated as a drafts folder or even require clients to use the folders designed a la RFC 6154 for that purpose; it's all convention and the client is allowed to do whatever it wants.

Finally, I would like to reiterate that there was clearly already the intent for Thunderbird to treat subfolders of drafts folders as drafts folders, since it "half works" in the sense that when you create a subfolder of your designed drafts folder the messages in it are treated like drafts.

TLDR there is no standards-based objection to Thunderbird supporting this. It would be useful to people. There was already at least half of an effort to make it work. I can't imagine why we would throw that away rather than finishing it.

Comment 41

[Wayne Mery (:wsmwk)]

Finally, I would like to reiterate that there was clearly already the intent for Thunderbird to treat subfolders of drafts folders as drafts folders, since it "half works" in the sense that when you create a subfolder of your designed drafts folder the messages in it are treated like drafts.

Unless we find code comments that indicate intention to support this, or a bug that intentionaly started to impliment this, I don't see how it can be claimed that anything seen as partially working is happening by intention.

Comment 42

[Jonathan Kamens]

The implementation of nsMsgDBFolder::IsSpecialFolder in mailnews/base/src/nsMsgDBFolder.cpp takes a boolean argument indicating whether a folder's ancestors should be checked to determine whether it is the specified kind of special folder. The code in mail/base/content/msgHdrView.js that calls it to determine whether to allow a user to edit a message as a draft in a particular folder, in particular, the function setDraftEditMessage(), sets that boolean argument to true. Someone made an intentional choice for it to behave this way.

The revision history in hg only goes back to 2008 and it was like this in the very first revision, so I know of no way to find the commit in which this decision was originally made so we can look at what the commit message said.

In any case, I am struggling to understand why the conversation we are having is "Was this the original intention many years ago" instead of "Would this be useful functionality that would benefit users".

Comment 43

[betterbird.project+10]

We've looked at the issue. The summary "Saving draft message opened from Drafts subfolder unexpectedly creates a new copy of the draft in main Drafts folder, resulting in multiple versions" is not strictly true. If you create a subfolder which also carries the drafts flag, you can use this add-on to set it, then the original draft is removed from the subfolder and the new draft is stored in the top drafts folder. If the subfolder doesn't have the drafts flag, deletion is prevented here:
https://searchfox.org/comm-central/rev/6187e08a6cba6e0534369e7a2aea025be66331c6/mailnews/compose/src/nsMsgCompose.cpp#3300,3345

The trouble is that new drafts/template are created in the send pipeline. The target folder for save is retrieved here from the account preferences:
https://searchfox.org/comm-central/rev/6187e08a6cba6e0534369e7a2aea025be66331c6/mailnews/compose/src/MessageSend.jsm#1000
The compose window is notified of the new location so it can subsequently remove intermediate drafts from the new location:
https://searchfox.org/comm-central/rev/6187e08a6cba6e0534369e7a2aea025be66331c6/mailnews/compose/src/MessageSend.jsm#1017

This is a complex matter. Imagine you have two identities. You edit a draft from the first one, while composing, you switch identities. So where you you want a saved draft to go now? Into the old location? Or into the location corresponding to the changed identity? Likely your answer will be: If the identity doesn't change, to the old location, otherwise to the new.

This patch should satisfy what you need, we settled for allowing subfolders of the identity's original draft folder. That should cover identity switching sufficiently:
https://github.com/Betterbird/thunderbird-patches/blob/main/115/bugs/263114-fix-save-draft-to-subfolder.patch
Likely the URL handling can be done more elegantly than with string substitution, but this works for now for IMAP, POP3 and local folders.

Comment 44

[gene smith]

Attachment: multiple-draft-subfolders.diff

This seems to work the way I think the reporters are expected. Reading this got me started:

From comment 30:

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.

However the parameter aMsgToReplace when doing a save to draft is always null so I had to find something else that determine the currently selected folder, new parameter aTargetMsgToReplace.

Here's how it works from the user perspective:

• I'm assuming you have a top level Drafts and several subfolders under it.

• If you compose a new message and save a draft it goes to the top level draft folder. You have to manually move it to a draft subfolder. (I don't think I saw any requests to allow selection of the subfolder before doing the save.)

• If you "edit as new" a message in any folder and save a draft, it will go to draft folder of the identity set on the message. If you want it to go to the current account or a different account draft folder you have to set an identify in the message for the correct account.

• If you edit as draft a messages in a top level Drafts' subfolder, it will save back to the same subfolder. I think this is the main requirement.

I've only tested this with imap draft/draft subfolders on the same imap server (icloud). I haven't tested with drafts in Local Folders or on another server. None of the changes are in imap specific code, so it should work.

Comment 45

[betterbird.project+10]

Thanks for presenting an alternative version. We tested IMAP, POP3 and News. POP3 works (local folder, but not "Local Folders"), news (draft in "Local Folders") moves the draft to the top folder (this bug) and IMAP gives the following when pressing Ctrl+S:

GenericSendMessage FAILED: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIMsgMessageService.messageURIToMsgHdr]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: resource:///modules/MessageSend.jsm :: _mimeDoFcc :: line 1032"  data: no] MsgComposeCommands.js:6392:13
NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIMsgMessageService.messageURIToMsgHdr] _mimeDoFcc resource:///modules/MessageSend.jsm:1032 MsgComposeCommands.js:6303:13

Comment 46

[gene smith]

Haven't seen a crash (edit: comment 45 shows a error, not a crash) when doing save of draft, even to a subfolder. So not sure what's going on there.
I did notice that editing drafts in subfolders didn't replace the original message but added a new message. This is because the subfolders were not having the ::Drafts flag set. When I set the flag for them, edited message get replaced and a new message is not added to the subfolder.
Also, yes, my patch doesn't help newgroups. For them the edit from a subfolder always goes back into the top level Drafts folder in Local Folders. (Not sure if anyone uses newgroups anymore so may not matter if this features isn't present for those accounts?)

Comment 47

[Alessandro Castellani [:aleca]]

Jumping on this train quite late, but I think this is also a UX issue.
If the user edits a draft message and saves it, the action should just override the originally opened draft message without changing location.

If you edit as draft a messages in a top level Drafts' subfolder, it will save back to the same subfolder. I think this is the main requirement.

Indeed, Gene, this is the desired result, thank you so much for tackling it.
Could you push your patch to Phabricator and as darktrojan for a review? Even if it's a WIP patch so we can help you out.

Comment 48

[gene smith]

Attachment: Bug 263114 - Allow edited drafts or templates in a subfolder to be saved back into the same subfolder. r=darktrojan,mkmelin

Currently a draft edited in a subfolder of Drafts is saved into the
top level Drafts folder and not into the original subfolder.
Ideally this should work for all protocols that support Drafts.
It may be possibe to extend this behavior to Template subfolders also.

Comment 49

[betterbird.project+10]

From Phab:

But instead of the string manipulation, probably you can get the folder URI from messenger.msgHdrFromURI(uri).folder.URI

Yes, the string manipulation was rather undesirable. Thanks for the hint, we've updated our patch. Tested with IMAP, POP3 and news/Local Folders.

Comment 50

[betterbird.project+10]

if (folderUri?.startsWith(this._folderUri)) { would be neater since if folderUri is null the entire term evaluates to null. Gene, can you adjust that and mark the comments "done".

Comment 51

[betterbird.project+10]

Another thought: If we want to cater for the deletion of the draft folder, ).folder?.URI is likely not enough since msgHdrFromURI() may already fail or return now. There will be no header for the draft/template ID. Worst case, this needs a try/catch, best case, another ? like so: )?.folder?.URI. Needs to be tested what happens if the subfolder is deleted while the draft is edited and then saved.

Comment 52

[betterbird.project+10]

Correction: ... fail or return null.

Comment 53

[betterbird.project+10]

Actually, for this to work at all, the subfolder needs to be a draft folder with the drafts flag. Those folders cannot be deleted or even renamed. You'd have to remove the flag (with an add-on) while editing the draft and then delete the folder. If you do that, nsIMessenger.msgHdrFromURI fails. So it needs a try/catch.

Comment 54

[gene smith]

Canceling check-in needed. Need to check what the problems is.
For one thing, I missed Magnus' requested for a change.

Comment 55

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/830feb6bf466
Allow edited drafts or templates in a subfolder to be saved back into the same subfolder. r=mkmelin

Comment 56

[Wayne Mery (:wsmwk)]

Comment on attachment 9352739 [details]
Bug 263114 - Allow edited drafts or templates in a subfolder to be saved back into the same subfolder. r=darktrojan,mkmelin

[Triage Comment]
Approved for beta

Comment 57

[Daniel Darnell [:dandarnell]]

Thunderbird 119.0b6:
https://hg.mozilla.org/releases/comm-beta/rev/a47a57f8abca

Comment 58

[Wayne Mery (:wsmwk)]

Good for 115?

Comment 59

[Jonathan Kamens]

In 115.4.2 if I move a draft into a subfolder and then open it for editing and save it, the draft is removed from the subfolder and a new draft is created in the main drafts folder. This isn't what I would consider the ideal behavior—I think the draft should be saved in the folder it came from—but it's certainly better than the previous behavior and addresses the specific problem represented by this ticket.

Comment 60

[gene smith]

(In reply to Wayne Mery (:wsmwk) from comment #58)

Good for 115?

Probably is.

This isn't something I've looked at since it was pushed to daily over two months ago. It has also been in 119b6 for a month.
The only comment I see is

(Jonathan Kamens from comment #59)

In 115.4.2 if I move a draft into a subfolder and then open it for editing and save it, the draft is removed from the subfolder and a new draft is created in the main drafts folder. This isn't what I would consider the ideal behavior—I think the draft should be saved in the folder it came from—but it's certainly better than the previous behavior and addresses the specific problem represented by this ticket.

and I don't exactly understand since, AFAIK, this patch is not yet in 115 at all and only in beta. So with beta, if you edit a draft in a subfolder of Drafts it will be saved back to the same subfolder as was specifically requested by the reporter in comment 0 and by more recent comments starting at comment 36.

Comment 61

[Wayne Mery (:wsmwk)]

Comment on attachment 9352739 [details]
Bug 263114 - Allow edited drafts or templates in a subfolder to be saved back into the same subfolder. r=darktrojan,mkmelin

[Triage Comment]
Approved for esr115

Comment 62

[Rob Lemley [:rjl]]

Thunderbird 115.5.2:
https://hg.mozilla.org/releases/comm-esr115/rev/73800b0d4579