Closed Bug 60578 Opened 24 years ago Closed 14 years ago

Mail message list "headers" (Thread, Subject, Sender, Read, Date and so on) should be pre-configurable or the configuration should be inherited from the first mailbox listed/configured

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: petter.sundlof, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: Recommend WONTFIX) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-test10 i686; en-US; m18) Gecko/20001117
BuildID:    2000111721

Mail message list "headers" (Thread, Subject, Sender, Read, Date and so on)
should be pre-configurable or the configuration should be inherited from the
first mailbox listed/configured.

I chose only to have Subject, Sender and Date listed. I also click on Date so
the latest message is listed on the top. I think one should be able to either
configure this by default, or make it so that the settings are inherited from
the first mailbox listed/configured.

Reproducible: Always
Steps to Reproduce:
1. Launch Mozilla
2. Open Mail, list contents in Mailbox.
3. Deselect some headers, change the order in let's say Date
4. Choose another mailbox; Date should be in the same order as the first (or
what I have specified in preferences)

Actual Results:  Does not use the same settings as the first mailbox	

Expected Results:  Should be the same as the first.
Reporter is this still a problem in the latest nightlies?
QA Contact: esther → nbaca
FYI
Build 2000-12-18-08: NT4, Linux 6.2, Mac 9.04
I don't see the problem in the 12/18 build.
Marking WORKSFORME as per comments. Reopen if its still a problem.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Verified Worksforme.
Status: RESOLVED → VERIFIED
Uhm uhm.

This still happens, using build 20001222. Let me illustrate with a couple of
imaegs, if it wasn't clear enough.

http://findus.dhs.org/~odd/mozbugs/m1.gif
http://findus.dhs.org/~odd/mozbugs/m2.gif
http://findus.dhs.org/~odd/mozbugs/m3.gif
http://findus.dhs.org/~odd/mozbugs/m4.gif

This is a Linux build.



Reopening

After selecting the Date column to change the sort order (latest messages
displayed first), this is not remembered when switching to another folder. I'm
not sure how this should work. 4.x does not remember the sort order for
different folders.
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
Oh, thanks for the clarification. I was concentrating on whether the column
choices were being saved, instead of the sort order.
Status: UNCONFIRMED → NEW
Ever confirmed: true
"4.x does not remember the sort order for different folders."

In my opinion Netscape 4.x is dumb in that particular aspect :)
actually, we should be saving the sort order for different folders. When you are 
using a folder for the first time we sort by date by default (and I think we 
sort ascending as well).  When you change the order it should stick with the 
folder from then on? Is it not doing this?

Reassigning to sspitzer.
Assignee: putterman → sspitzer
Build 2000-12-29-04: NT4, Linux 6.2
Build 2001-01-02-08: Mac 9.04
The Sort order appears to be working as putterman describes.

I think this should be marked as WORKSFORME or as WONTFIX. The whole concept of
multiple folders is so you can have different sorting practices/headers then the
other folders.
Whiteboard: Recommend WONTFIX
I think having each folder remember its settings is much better, since Inbox is
usually sorted by Date, but I know number of people (including me) who prefer to
have Outgoing mail sorted by e-mail/recipient.
What I'm advocating is not that, mayo@nfy.ca!

After the first listing of Inbox, the following folders should use that as the
default, but the user should be able to make exceptions, of course.
Re: sorting messages by category---if a msg header is displayed and selected
before sorting, it would be nice for that selection to continue to be displayed
after sorting. In the current build (1.2b), the sorting moves the selection
off-screen in general. Sorting is a quick way to find all msgs to or from
someone, for example, and it's a nuisance to then scroll up or down the header
list to find the highlighted header.

This usability issue is something that people have repeatedly expressed as being
important to their serious use of Mozilla as an email client.

We are now up to Release Candidate 1.4-something and this hasnt been fixed yet.

I see on the status box of this usability bug that the recommendation is
WONTFIX. This would be a mistake for all the hard-working people who contribute
to Mozilla, as there really are alternative email clients. Adding a few lines to
read the contents of the "From" or "To" header line, displaying it along with
all the others, and enabling sorting and filtering to work on that additional
piece of header information ought to be a piece of cake, and a suggestion
gratefully received by those who would like Mozilla to continue to be a success.

John

John T, your comments make little sense in the context of this bug, and appear
to address several different bugs.

comment 14 complains that a selected record can be scrolled out of the thread
pane on a sort.  This is bug 186999. 

comment 15 seems to ask for columns that are specific to To: or From: -- as
opposed to the current 'address' column which displays From: except for the Sent
and Drafts folders, which show To:.  If in fact that is what you want, see bug
36492.  I do not know what you mean by "filtering" in that sentence, as
filtering is unrelated to columns.

For reference, the bug about configuring columns per-folder is bug 148901.

As far as I can tell, the suggested WONTFIX applies to the reporter's request to
'inherit' the sort order when opening a new folder -- or some means to set the
default sort order; this is bug 86845.
Blocks: 236849
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
Priority: P3 → --
QA Contact: nbaca → message-display
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
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: 24 years ago → 14 years ago
Resolution: --- → EXPIRED
As per comment 16, all issues are either solved or extension fodder (eg. see Mnenhy's folder storage).
Resolution: EXPIRED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.