Closed Bug 65962 Opened 24 years ago Closed 15 years ago

Next button should take into account the ordering of messages

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Linux
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: pratik.solanki, Unassigned)

Details

1. Order any account with multiple new mails in the descending order. newest mail first. 2. Click on Next. Result: Next opens the first message from the top which is last message that arrived (assuming sorted on order received). Consecutive presses go through messages from top to bottom. Desired Behaviour: Next should take into account the sorting order and go from bottom to top is the order is descending. That way if I have mails sorted by 'Order received' and descending and I press Next, I read mails in the order that they were received.
I'm pretty sure this is a DUP.
QA Contact: esther
QA Contact: fenella
I couldn't find a duplicate. Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Found it :) *** This bug has been marked as a duplicate of 54593 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verified dup.
Status: RESOLVED → VERIFIED
This wasn't implemented in bug 54593, so I'm re-opening this for re-evaluation.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
QA Contact: fenella → laurel
I think I strongly disagree with the desirablity of this as written. If the user has selected descending date sort, then "taking into account the ordering" should, IMNSHO, read youngest first and then backward in time. IOW, the "Next/Forward/Backward/Prior" should mean _exactly_ "Down / Up" with respect to the user's current ordering of the message list. If reporter wants to read in order received, she can easily order the list that way! -1
I agree with this bug. This has annoyed me very much. I have my mails ordered by Date, with the last at the top. Next is completely useless to me as it, as the bug submitter said, goes to the mail at the top and then descends. Casting a precious vote on this =)
This problem also affects deleting messages when using IMAP in "Mark as deleted mode". If you delete a message the focus moves down to mail you have already read/deleted rather than up to the next new message. Hence requiring the user to press the "Up" arrow key twice after every delete. Either the delete operation shouldn't move anywhere allowing the user to decide which way to go, or it should move in the natural date order regardless of the sort order (or at least provide the user an option to enforce this behaviour).
comment #6: Then we should rename the buttons, up, down. (and you basically have that now with the b, f, p & n keys. But until that happens, the concept of next and prev should be thought of (ie the basis of this bug) comment #8: This should be split off as a seperate bug. Please check to see if another bug covers this, and if none found, report a new bug, and give the number here (for reference)
is bug 118508 dupe of this? what is this bug asking? that Next unread message should always go to the next message by order of receipt?
Severity: normal → enhancement
BTW, I disagree about reclassifying as "enhancement," FWIW Replying to Comment#10 -- At least, this is how /I/ interpret it. Any time you are reading a Message, you came there from a particular displayed list of messages -- usually the 3-pane display. Consider that display as the "context" of the message you are reading; it has a user-selected ordering including the threadedness. This is a complete ordering: for any message 'M' there is a well-defined 'Next' and 'Prior' WITH RESPECT TO THE DISPLAYED LIST OF MESSAGES. This bug proposes that the navigation functions always follow that ordering. This seems to mean that the responsibility to determine where to go when navigating must be passed back "up" the call tree to the logic maintaining the list display. Now, as an added benefit if you will, doing that could add a 'nice to see' feature of moving the highlight in the list as one navigates. That does leave unresolved what to do if two stand-alone displays are "called" from the same display list. FWIW. Another way of looking at it: Picture yourself reading messages using the full 3-pane display: the "current" message in the message-pane is whatever is selected in the message-list-pane (nicht wahr?). Now consider the standalone message display resulting from selecting "display in new window" to be exactly a redisplay of the message-pane in a window of its own. Again, the concept of movement is relative to the displayed list - not to any intrinsic property of the folder being displayed. I've been called long-winded once or twice! I wonder why.
*** Bug 118508 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Status: REOPENED → NEW
Assignee: mail → nobody
QA Contact: laurel → 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 → 15 years ago
Resolution: --- → EXPIRED
Ever confirmed: true
This is clearly WFM (and if it was meant otherwise, it'd be WONTFIX).
Resolution: EXPIRED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.