95709 - Change the Sent folder, difficult to get it back to a normal state

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Ninoschka Baca]

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.

Comment 1

[Ninoschka Baca]

Attachment: 2 folders appearing as Sent folders

Comment 2

[Ninoschka Baca]

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.

Comment 3

[(not reading, please use [e-mail] instead)]

dollars to donuts says we're not clearing the "sent" folder flag.

that would explain this bug, and some related bugs.

yikes!

Comment 4

[Scott MacGregor]

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

Comment 5

[(not reading, please use [e-mail] instead)]

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.

Comment 6

[(not reading, please use [e-mail] instead)]

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

Comment 7

[(not reading, please use [e-mail] instead)]

ignore my last comments, wrong bug.

Comment 8

[Ninoschka Baca]

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

Comment 9

[(not reading, please use [e-mail] instead)]

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 

Comment 10

[Jaime Rodriguez, Jr.]

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

Comment 11

[selmer (gone)]

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

Comment 12

[(not reading, please use [e-mail] instead)]

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.

Comment 13

[(not reading, please use [e-mail] instead)]

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

moving out.

Comment 14

[scottputterman]

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

Comment 15

[Thorsten Kaiser]

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?

Comment 16

[laurel]

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

Comment 17

[Peter Trudelle]

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

Comment 18

[Thorsten Kaiser]

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

Comment 19

[Judd Rogers]

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

Comment 20

[Robert Kaiser]

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

Comment 21

[Robert Kaiser]

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

Comment 22

[Robert Kaiser]

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

Comment 23

[Robert Kaiser]

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

Comment 24

[Robert Kaiser]

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

Comment 25

[Robert Kaiser]

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

Comment 26

[Robert Kaiser]

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

Comment 27

[Robert Kaiser]

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

Comment 28

[Karsten Düsterloh]

WFM.