Build 2001-08-15-04: WinMe Haven't tried mac or linux yet. Overview: Change the Sent folder to something other than the default (i.e. Folder1) so the column in the thread pane changes from "Sender" to "Recipient". Change it back and you get into a state where the recipient always displays in the thread pane and the columnn is title "Recipient". Steps to reproduce: 1. Open Account Settings by selecting Edit|Mail/News Account Settings 2. Select the Copies and Folders panel (I was using an IMAP account) 3. Change the Sent folder from the default to any regular folder (i.e. Folder1). Notice the Sender column is now titled "Recipient" and it displays the recipient's email address. 4. Send a message and a copy of the message appears in Folder1 5. Open Account Settings and go to Copies and Folders again to change the Sent folder back to the default, OK 6. Select Folder1 and the column is now titled "Sender" and displays the sender's email address, as expected. 7. Exit/restart Actual Results: It doesn't appear that the changes were saved. "Folder1" still appears to be a special folder because it has an arrow pointing to the right. Select Folder1 and it now shows a "Recipient" column and displays email addresses for the recipient. "Sent" also appears to be a special folder. When I send a message, a copy is placed in the "Sent" folder so it is placing the message in the correct folder. It appears that once a folder is defined as a Sent folder, it remains in that state so it will only show the Recipient's email address. Expected Results: Once a folder is no longer a "Sent" folder then: 1. The folder icon should appear as a normal folder (no arrow) 2. The thread pane should have a Sender column 3. The email address displayed should be the sender's email address. 4. The change should be saved, even after an exit/restart.

Another scenario: I set my Inbox folder to be the Sent folder, then changed it back to the default, after an exit/restart the column displayed "Sender" when actually the recipient's email addresses were being displayed. I found this bug when looking at bug# 72791.

dollars to donuts says we're not clearing the "sent" folder flag. that would explain this bug, and some related bugs. yikes!

plusing in case the problem really is that we aren't clearing the sent folder flag.

w.r.t the initial problem reported, a couple things are going on. ninoschka, do you have multiple profiles set up? if so, you may have more than one account pointing to your sent folder. if you do, when you switch a single account's sent folder to another folder, and then restart, that would explain why the sent folder remains a sent folder. I've logged another bug to cover this issue, see #100242 I've logged bug #100239 to cover the issue where the sent folder icons don't update until restart. now I'll go investigate the second scenario.

I think your fix for #95320 isn't necessary. once you've removed the connection from the cache, it won't get re-used.

ignore my last comments, wrong bug.

Seth, are you asking if I have multiple accounts in 1 profile or multiple profiles as listed in Profile Manager?

ninoschka: multiple accounts in 1 profile. if you've got multiple identities, they could each point to the same sent folder. so if one identity changed sent folders (or was deleted) a folder could still remain a "sent" folder if another identity pointed to it. that issue is covered by bug #100239

Adding correctness Status Whiteboard, correct/expected behavior does not occur.

I don't see an answer to the question about clearing the sent flag. Do we know yet? How serious is the impact of this bug, seems like something that would almost never happen. I'm marking this PDT-, if you have a *strong* reason why that's wrong please add it here and remove the PDT-.

it's not just a matter of clearing or setting a flag. the fix that's needed to address this issue is going to be too much for the branch. minusing, it will have to come next release.

I'd like to resolve the general problem, but no time right now. moving out.

esther, this sounds like one of the problems you were investigating.

Sorry if I miss the point, but here is my view on this bug (some may be obvious to you): 1) In the original "Sent" folder (i.e. the one which is automatically created with each mail account) always the recipient should be displayed. 2) If the original "Inbox" folder (i.e. the one which is automatically created with each mail account) is configured to keep sent messages, it should nevertheless always display the sender. Any other behaviour would be pretty much useless IMHO. 3) In any other case it may be a folder property wether to display sender or recipient when used as sent folder. Or it may be according to 2) or 1). I don´t really care... I used a setting according to 2) for years with NS4.x. Since 3 months Mozilla is my default browser and mail application. I did apply the same configuration with Mozilla. I don´t mind some crashes (at least not too much) but this wrong behaviour of the Inbox folder really bothers me a lot. BTW, I dont´t think this setting is very unusual, so it may improve Moz usability even more. Conclusion: I strongly support behaviour of Inbox according to 2). What are your views on this?

*** Bug 92774 has been marked as a duplicate of this bug. ***

nsbeta1- per ADT triage, ->1.2, blocks 'miracle bug' 122274

Sorry for the SPAM, but I feel I have to express my frustration: Will we ever see a fix landing for this one? Since I observe this bug, it appears to be virtually rushing away with regard to target milestone...

I agree with Thorsten in comment #15: behavior 2 is consistent with Navigator and the behavior one would want.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420

WFM.