Closed Bug 95709 Opened 23 years ago Closed 14 years ago

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

Categories

(SeaMonkey :: MailNews: Message Display, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: nbaca, Unassigned)

References

Details

(Whiteboard: [correctness])

Attachments

(1 file)

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.
Keywords: nsBranch
dollars to donuts says we're not clearing the "sent" folder flag.

that would explain this bug, and some related bugs.

yikes!
Blocks: 99230
plusing in case the problem really is that we aren't clearing the sent folder flag. 
Keywords: nsbranchnsbranch+
Target Milestone: --- → mozilla0.9.5
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.
Status: NEW → ASSIGNED
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.
Whiteboard: [correctness]
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-.
Whiteboard: [correctness] → [correctness] 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.
Keywords: nsbranch+nsbranch-
OS: Windows ME → All
Hardware: PC → All
Target Milestone: mozilla0.9.5 → mozilla0.9.7
I'd like to resolve the general problem, but no time right now.

moving out.
Blocks: 107067
Keywords: nsbranch-
Target Milestone: mozilla0.9.7 → mozilla0.9.9
esther, this sounds like one of the problems you were investigating.
Keywords: nsbeta1+
Priority: -- → P2
No longer blocks: 107067
Whiteboard: [correctness] PDT- → [correctness]
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. ***
Target Milestone: mozilla0.9.9 → mozilla1.0
nsbeta1- per ADT triage, ->1.2, blocks 'miracle bug' 122274
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
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.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Status: ASSIGNED → NEW
Assignee: mail → nobody
Priority: P2 → --
QA Contact: esther → message-display
Target Milestone: mozilla1.2alpha → ---
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
Status: NEW → UNCONFIRMED
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
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
WFM.
Resolution: EXPIRED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: