From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9) Gecko/20010505 BuildID: 2001050515 The normal behaviour in this build is that, if I double-clic a message placed on the folder 'Drafts', a composition message appears with the contents of that message. However, if we create a subfolder inside the 'Drafts' folder and we place there a draft message, when we open it Mozilla will display a normal mail message (but not editable, not a compose message window). Reproducible: Always Steps to Reproduce: 1. Create a subfolder inside 'Drafts' folder, called, for instance, 'SubDrafts'. 2. Move a message from 'Drafts' to 'SubDrafts' 3. Open 'SubDrafts' to view the messages in it. 4. Double-clic the message you just have moved. Actual Results: Display a normal message window. Expected Results: Display a composing-editable message window.

Not a mail database issue. Reassigning to JF since it's sort of a drafts issue, I guess...

The problem is still here in Mozilla 0.9.1 (build ID 2001060703). All messages placed on folder drafts now have a new option button called "Edit Draft...". However, drafts messages placed on a Drafts subfolder have not this option and cannot be edited. Is this bug going to be confirmed?

Bug still present on Mozilla 0.9.2 (Build ID 2001062815)

I think the method to solve this bug is very related to a comment that Seth Spitzer has included on bug 61651. I will quote it: >If someone wants to fix this (before I get time to do it), here's what we need >to do to: > >IsSpecialFolder() and IsSpecialFolderSelected() in[commandglue.js and >threadPane.js (respectively)] need to be fixed. > >what the code currently does is takes the current folder and checks the flags. > >what it needs to do is this: > >check the current folder's flags, if that doesn't return true, try again with >the folders parent. (see the nsIFolder interface). > >I'm not sure if parent will come back as null, or if you have to check if the >folder is a server to stop the while loop. > Marking dependency on bug 61651.

I submitted a patch to 61651 that also fixes this bug.

reassign to varada. This is a mail3pane issue which decide which folder is a draft folder.

I think this bug is not completely fixed (that's why I hacen't changed it to FIXED) because: although now messages on drafts subfolders show the option "Edit draft..." the column "recipient" associated with these messages show the "sender" information, instead of the recipient one. The same occurs with Sent subfolders, as seen on bug 61651. Should we reopen bug 61651 and leave this as new, or open a new one which explains the bug associated with any type of subfolder? Or is already a bug that describes this? Anyone know?

Resolving to FIXED, because a new and confirmed bug has been opened (bug 101162) which shows the regression of bugs 82909 and 61651.

Marking verified. Original problem fixed and working. Sent subfolder problem is documented in other bug report(s).