User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1 Build Identifier: 2008072418 Once you set the draft folder (Edit, Account Settings, Copies & Folders, Drafts and templates from a folder on Imap ("Drafts" Folder on:") to a local one ("Other: Drafts") thunderbird continues to store drafts in the original folder, ignoring the setting change Reproducible: Always Steps to Reproduce: 1.On an imap account, go to Edit, Account Settings, Copies & Folders and set the draft folder to a folder on your imap account 2.Compose an email. Don't send, click save to draft folder: it will be stored correctly 3.Go to Edit, Account Settings, Copies & Folders and set the draft folder to local folder 4. Click on save again on the previous email: the email is stored still in the imap drafts folder. 5. Close the email, destroy it. Make a new one. 6. Click on save. The email is still being stored in the imap folder, regardless of the setting Actual Results: Once the draft folder has been set to an imap folder, there's no turning back: emails are forever saved in the imap folder, even if the setting is reverted Expected Results: The email is always saved in the imap draft folder On step 4 and 6, the message should have been saved on the local folder

can you reproduce with trunk build?

I have the same bug with Thunderbird 2.0.0.23 on Ubuntu 9.04

I couldn't see problem of bug summary with Tb 2.0.0.23 on Win-XP. When draft for an account(main identity) or identity(Manage Identities) is changed while editing draft mail in old draft folder, Tb saved it in newly selected draft folder when "Save As Draft". > Steps to Reproduce: >(snip) > 4. Click on save again on the previous email: the email is stored still in the imap drafts folder. Really new version of draft mail was saved in old draft mail folder? Old version was not deleted, wasn't it? Next phenomenon was observed with Tb 2.0.0.23. Old draft mail in old draft folder is not deleted upon next "Save As Draft (and/or Send/Send Later)". I think phenomenon can be said as next; "Remove of old draft mail" is tried for "new draft folder" instead of "old draft folder", then old draft mail in old draft folder is not deleted. Anyway, if bug summary is problem of this bug, INVALID, because Tb saves draft mail to newly requested folder to save draft mail.

> Steps to Reproduce: >(snip) > 4. Click on save again on the previous email: the email is stored still in the imap drafts folder. If you check next setting, dialog for "where draft is saved" is displayed. > Copies&Folders > [ X ] Show confirmation dialog when messages are saved To which account's folder does the dialog say when you do "Save As Draft"? Note: If subfolder such as [Gmail]/Drafts is chosen, lowest level name only ("Drafts" instead of "[Gmail]/Drafts") is displayed at the dialog.

Actually, say I go to "Edit > Account Settings > Copies & Folders", set the draft folder to local folder and click on "OK", if I return to this window, I see that my setting hasn't been saved, so it's always reset to the draft folder of the IMAP account.

(In reply to comment #5) > so it's always reset to the draft folder of the IMAP account. "has no effect" in bug summary meant it? Changed via "Drafts folder on: [ Local Folders ]"? "Drafts" of "Local Folders" exists? Other folder setting properly points existent mail folder? Select existent folder via "Others:" for all folders. (1) Copies & Folders of account, identity (2) Junk Settings of account Is Drafts setting change saved?

Probably same problem as Bug 143485. See Bug 221386 for same phenomenon due to incorrect path setting for Copies&Folders which is produced by anti-virus software's mail.server.serverX.hostname change. If current Tb trunk, phenomenon becomes Bug 471344, "OK" at Copies&Folders does do nothing if incorrect path setting for Copies&Folders exists(also on Junk Settings if wrong Junk folder path).

(In reply to comment #6) > (In reply to comment #5) > > so it's always reset to the draft folder of the IMAP account. > > "has no effect" in bug summary meant it? I don't know. Does it mean that the draft folder modification isn't saved in our preferences and it's always reset, or that it's saved but not used? > Changed via "Drafts folder on: [ Local Folders ]"? I tried both "Drafts folder on: [ Local Folders ]" and "Others:". > "Drafts" of "Local Folders" exists? Yes. It works for all my accounts, except IMAP. > Other folder setting properly points existent mail folder? Yes. > Select existent folder via "Others:" for all folders. > (1) Copies & Folders of account, identity > (2) Junk Settings of account > Is Drafts setting change saved? No. I have the same problem for "Templates" folder too.

Copies&Folders setting is saved in next prefs.js entry for each identity. Drafts : mail.identity.idX.draft_folder mail.identity.idX.drafts_folder_picker_mode Sent : mail.identity.idX.fcc mail.identity.idX.fcc_folder mail.identity.idX.fcc_folder_picker_mode Templates : mail.identity.idX.stationery_folder mail.identity.idX.tmpl_folder_picker_mode (dialog) mail.identity.idX.showSaveMsgDlg = true or false What is set by you? (1) Find mail.server.serverP.xxx for the IMAP account. Check for xxx=hostname,realhostname,userName,realUsername. (2) Find accountN for serverP. mail.account.accountN.identities = idA, ..., idF (first idA=main identity) mail.account.accountN.server = serverP (3) Check above setting for all of idA, ... ,idF. (In reply to comment #8) > Does it mean that the draft folder modification isn't saved in > our preferences and it's always reset, or that it's saved but not used? If pointer to folder in prefs.js is wrong(non-existent, folder of hidden account, ...), phenomenon of Bug 472959 occurs if Tb trunk. (Bug 472959 is for Junk, but same problem occurs on Drafts etc. too) If Tb 3, phenomenon is "Tb does do nothing when OK is clicked". If Tb 2, AFAIR, phenomenon was "panel is closed by OK but change is not saved in prefs.js". So I asked you about pointer to non-existent folder in prefs.js. It's already ruled out by your answer.

(In reply to comment #9) > Copies&Folders setting is saved in next prefs.js entry for each identity. > Drafts : mail.identity.idX.draft_folder > mail.identity.idX.drafts_folder_picker_mode > Sent : mail.identity.idX.fcc > mail.identity.idX.fcc_folder > mail.identity.idX.fcc_folder_picker_mode > Templates : mail.identity.idX.stationery_folder > mail.identity.idX.tmpl_folder_picker_mode > (dialog) mail.identity.idX.showSaveMsgDlg = true or false > > What is set by you? Here are the values found in prefs.js: user_pref("mail.identity.id7.draft_folder", "imap://user@imap.server.ext/Drafts"); user_pref("mail.identity.id7.drafts_folder_picker_mode", "0"); user_pref("mail.identity.id7.fcc_folder", "mailbox://nobody@Local%20Folders/Sent/my-folder"); user_pref("mail.identity.id7.fcc_folder_picker_mode", "257"); user_pref("mail.identity.id7.stationery_folder", "imap://user@imap.server.ext/Templates"); user_pref("mail.identity.id7.tmpl_folder_picker_mode", "0"); mail.identity.id7.showSaveMsgDlg: not found in prefs.js > (1) Find mail.server.serverP.xxx for the IMAP account. > Check for xxx=hostname,realhostname,userName,realUsername. user_pref("mail.server.server5.hostname", "imap.server.ext"); mail.server.server5.realhostname: not found in prefs.js mail.server.server5.realUsername: not found in prefs.js user_pref("mail.server.server5.userName", "user"); > (2) Find accountN for serverP. > mail.account.accountN.identities = idA, ..., idF (first idA=main identity) > mail.account.accountN.server = serverP > (3) Check above setting for all of idA, ... ,idF. user_pref("mail.account.account5.identities", "id7"); user_pref("mail.account.account5.server", "server5");

(In reply to comment #10) > user_pref("mail.identity.id7.fcc_folder", "mailbox://nobody@Local%20Folders/Sent/my-folder"); > user_pref("mail.identity.id7.fcc_folder_picker_mode", "257"); > mail.identity.id7.showSaveMsgDlg: not found in prefs.js (1) mail.identity.id7.showSaveMsgDlg: not found in prefs.js It's for [ X ] Show confirmation dialog when messages are saved Check this option to know where draft is saved. (2) No mail.identity.idX.fcc It's for [ ] Place a copy in / Sent folder of ... You don't need copy of sent mail? (3) user_pref("mail.identity.id7.fcc_folder_picker_mode", "257"); I don't know about fcc_folder_picker_mode=257. I saw 0(Sent folder of account...) or 1(Others:) only in the past. I think fcc_folder_picker_mode=257 is culprit. Somehow fcc_folder_picker_mode=257 is set wrongly, and problem of Bug 472959 occurs. And, as Tb 2, phenomenon is "change of drafts path is not saved" (Bug 143485, Bug 221386). (i) Set fcc_folder_picker_mode=0 and restart Tb. (ii) Check "[ ] Place a copy" for sent folder. (iii) Select folder to save sent mail. (iv) Check "[ X ] Show confirmation dialog ...". (v) Change drafts setting("Drafts" under Local Folders). Is change of drafts setting saved in prefs.js normally? Is draft mail saved to folder of Local Folders?

I couldn't reproduce phenomenon of "drafts setting change is not saved" by fcc_folder_picker_mode=257, with Tb 2.0.0.23, Tb trunk 2009/9/07, on MS Win-XP. Tb displayed "Sent folder on : <account pointed by mail.identity.idX.fcc_folder>" as checked. Tb's logic seems next. If fcc_folder_picker_mode=1 then "Others:", else "Sent folders on:". And, change of drafts folder setting was saved in prefs.js. "Setting change of drafts while mail composing" was also effective as expected. What version of Tb do you use? Can you reproduce your problem with -safe-mode of Tb? Are you taking about phenomenon of "old draft mail in previous Drafts(IMAP's Drafts in your case) is not deleted"?

(In reply to comment #11) > (In reply to comment #10) > > user_pref("mail.identity.id7.fcc_folder", "mailbox://nobody@Local%20Folders/Sent/my-folder"); > > user_pref("mail.identity.id7.fcc_folder_picker_mode", "257"); > > mail.identity.id7.showSaveMsgDlg: not found in prefs.js > > (1) mail.identity.id7.showSaveMsgDlg: not found in prefs.js > It's for [ X ] Show confirmation dialog when messages are saved > Check this option to know where draft is saved. I added user_pref("mail.identity.id7.showSaveMsgDlg", true); in prefs.js. > (2) No mail.identity.idX.fcc > It's for [ ] Place a copy in / Sent folder of ... > You don't need copy of sent mail? I use the addon "Copy Sent to Current" to have a drop-down list of "Sent folders" in my edit window. > (3) user_pref("mail.identity.id7.fcc_folder_picker_mode", "257"); > I don't know about fcc_folder_picker_mode=257. > I saw 0(Sent folder of account...) or 1(Others:) only in the past. > > I think fcc_folder_picker_mode=257 is culprit. > Somehow fcc_folder_picker_mode=257 is set wrongly, and problem of Bug 472959 > occurs. And, as Tb 2, phenomenon is "change of drafts path is not saved" (Bug > 143485, Bug 221386). > > (i) Set fcc_folder_picker_mode=0 and restart Tb. Done directly in prefs.js. > (ii) Check "[ ] Place a copy" for sent folder. I deactivated the addon "Copy Sent to Current" and checked "Place a copy" for sent folder. > (iii) Select folder to save sent mail. I selected sent folder on Local Folders. > (iv) Check "[ X ] Show confirmation dialog ...". Done for drafts and templates. I don't see this option for sent folder. > (v) Change drafts setting("Drafts" under Local Folders). Done. > Is change of drafts setting saved in prefs.js normally? Yes! > Is draft mail saved to folder of Local Folders? Yes, and the dialog confirms it.

(In reply to comment #12) > What version of Tb do you use? Mozilla Thunderbird version 2.0.0.23 (20090817), on Ubuntu 9.04. > Can you reproduce your problem with -safe-mode of Tb? If I launch "thunderbird -safe-mode", the problem is not there, but maybe because all the changes made in comment #13? > Are you taking about phenomenon of "old draft mail in previous Drafts(IMAP's > Drafts in your case) is not deleted"? I don't totally understand.

(In reply to comment #14) > If I launch "thunderbird -safe-mode", the problem is not there, but maybe > because all the changes made in comment #13? Safe-mode removes extensions and themes. If you still have the issue without -safe-mode then an extension or a theme is playing tricks. try disabling them all and re-enable them one by one to see which one causes your issue.

Although I cannot reproduce this bug, I came here because of a core source problem that I have discovered. In MsgComposeCommands.js at http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#2131 there is a line: gMsgCompose.SendMsg(msgType, getCurrentIdentity(), currentAccountKey, msgWindow, progress); The currentAccountKey is determined earlier in the function. However, the code that determines the currentAccountKey only executes: if (msgType == nsIMsgCompDeliverMode.Now || msgType == nsIMsgCompDeliverMode.Later || msgType == nsIMsgCompDeliverMode.Background) that is, not for drafts. So I am getting undefined for currentAccountKey going into SendMsg for drafts. Somehow that still does not cause the save to fail in my case, but it is clearly an oversight, and under some conditions might cause some issues.

that's quite possibly an error - but I wonder why we whitelist msgTypes - I wonder what the blacklist looks like and why...

(In reply to David :Bienvenu from comment #17) > that's quite possibly an error - but I wonder why we whitelist msgTypes - I > wonder what the blacklist looks like and why...

Looks like the list of valid msgTypes is longer today: http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#2758 Rkent, is the problem still existing?

As to the draft folder not saving the value or OK button not working, I am working on some bugs of this kind. WADA has already pointed some out or you can start following bug 536768 where I am thinking out the sanitizing infrastructure and can maybe extend it to other config panels/bugs.

I'd just like to confirm this bug (17.0.2). In fact, not just when trying to change to drafts folder on Local, but any folder, Local or the same IMAP server or another one. The configuration values (for both "Drafts folder on X" or "Other") will save but appear to have no effect whatsover.

It looks like the problem from comment 16 is solved today, the code is gMsgCompose.SendMsg(msgType, getCurrentIdentity(), getCurrentAccountKey(), msgWindow, progress); So the uninitialized account key should not be there.

(In reply to report0 from comment #21) > I'd just like to confirm this bug (17.0.2). (snip) We have already two reports in this bug for draft setting related issues. Your case is third case. (Case-1) Original bug report(Comment #0) case by bug opener. Bug summary is following by bug opener aince initial to today. > Changing draft folder from an Imap folder to a local folder has no effect Original bug report of this bug. > comment #0 : by Miquel Martin(bug opener) on 2008-08-06 No response from bug opener. (Case-2) Comment #2 to comment #14 by Jean-Philippe Fleury > Comment #2 Jean-Philippe Fleury 2009-09-05 20:22:09 PDT > I have the same bug with Thunderbird 2.0.0.23 on Ubuntu 9.04 > > Comment 10 Jean-Philippe Fleury 2009-09-09 12:59:07 PDT > > user_pref("mail.identity.id7.draft_folder", "imap://user@imap.server.ext/Drafts"); > user_pref("mail.identity.id7.drafts_folder_picker_mode", "0"); > user_pref("mail.identity.id7.fcc_folder", "mailbox://nobody@Local%20Folders/Sent/my-folder"); > user_pref("mail.identity.id7.fcc_folder_picker_mode", "257"); > > Comment #13 Jean-Philippe Fleury 2009-09-10 06:09:24 PDT > > I use the addon "Copy Sent to Current" to have a drop-down list of "Sent folders" in my edit window. > > > (i) Set fcc_folder_picker_mode=0 and restart Tb. > Done directly in prefs.js. > > (ii) Check "[ ] Place a copy" for sent folder. > I deactivated the addon "Copy Sent to Current" and checked "Place a copy" for sent folder. > > (iii) Select folder to save sent mail. > I selected sent folder on Local Folders. > > (iv) Check "[ X ] Show confirmation dialog ...". > Done for drafts and templates. I don't see this option for sent folder. > > (v) Change drafts setting("Drafts" under Local Folders). > Done. > > Is change of drafts setting saved in prefs.js normally? > Yes! > > Is draft mail saved to folder of Local Folders? > Yes, and the dialog confirms it. > Comment 14 Jean-Philippe Fleury 2009-09-10 06:31:33 PDT > > What version of Tb do you use? > Mozilla Thunderbird version 2.0.0.23 (20090817), on Ubuntu 9.04. > > Can you reproduce your problem with -safe-mode of Tb? > If I launch "thunderbird -safe-mode", the problem is not there, but maybe because all the changes made in comment #13? (Case-3) Your case. > Comment 21 report0@diamondsky.org (New to Bugzilla) 2013-02-27 04:13:36 PST > I'd just like to confirm this bug (17.0.2). > In fact, not just when trying to change to drafts folder on Local, but any folder, Local or the same IMAP server or another one. > The configuration values (for both "Drafts folder on X" or "Other") will save but appear to have no effect whatsover. Confirmed what of problems reported in this bug, comment #0 on 2008-08-06(still no response), and Comment #2 on 2009-09-05(addon problem)? As already known by (Case-2) which was caused by addon, addon can produce phenomenon stated in bug summary. And, "check with addon disabled" was requested in (Case-2). Have you checked with "addon disabled"? > The configuration values (for both "Drafts folder on X" or "Other") will save (snip) As seen in (Case-2), draft relevant settings is already written in this bug. What is set in prefs after your the "configuration value change" and save of it? > but appear to have no effect whatsover. What phenomenon do you call by "have no effect"? If phenomenon is "saved setting change was somehow reset by someone" when you try to save draft, is when the "saved your setting change" reset or altered? If phenomenon is "Draft setting change via UI is not saved", bug is already pointed by comment #20. Have you read the pointed bug? However, if that bug, IIRC, phenomenon was "OK button does do nothing and Cancel is needed to quit from Draft UI" like one, and chage we want won't be saved at anywhere. What is your actual operation?

Thank you for your reply. Unfortunately, I can no longer provide details for the cause of the symptoms, as ever since launching in safe mode the problem no longer exists - even when now running in non-safe mode. My guess is, prefs.js or some other file was previously corrupted and somehow was permanently fixed by launching in safe mode.

(In reply to :aceman from comment #22) > It looks like the problem from comment 16 is solved today, the code is > gMsgCompose.SendMsg(msgType, getCurrentIdentity(), getCurrentAccountKey(), > msgWindow, progress); > > So the uninitialized account key should not be there. Given comment 20, is this problem now gone?

I don't know, I have never reproduced it, only comment on the code. We need info from the reporter or others seeing the problem.