80604 - Thread Pane Should Move to Top for New Messages

Status: RESOLVED WONTFIX

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Ben Ruppel]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010513
BuildID:    2001051308

As of right now, when I open MailNews and I have new messages, they are
automatically downloaded, but the thread pane stays at the top of the old
messages.  It should move to the very top of the list.  Now I have to scroll up
in order to see new messages.  (this is assuming that the user sorts new
messages to be at the very top).  This brings up questions of which is the
"right" way (new messages topmost or bottommost), but I think I'll bring that up
in another bug.

Reproducible: Always
Steps to Reproduce:
0.Have messages sort so newest are on top
1.Get new email
2.Open up MailNews and select inbox of appropriate account


Actual Results:  New messages are downloaded, but thread pane does not move to
the new top.

Expected Results:  The thread pane should be at the top.

I'm going to file a related bug, requesting for initial thread pane position to
follow sorting.

Comment 1

[Alexey Chernyak]

When you are at the top of the list and you get new messages, it does the right
thing.
However the problem, I believe, is that when you open Messenger, the threadpane
is at the second topmost message, not the first one. So when you get new
messages it just stays at the second message.

If you scroll to the very top of the list prior to getting mail, it works correctly.

Comment 2

[Ben Ruppel]

Ohhhhhhhhhhhhhhhhhhh.  
I see.  Sorry about the invalid bug then.  Thanks.
Do you know offhand the bug for this, so that I can go vote for it? :)

Comment 3

[Chase Tingley]

Marking invalid per reporter's comments.

Comment 4

[Ben Ruppel]

Actually, I think I'm still right here.  When I get multiple new messages,
mailnews doesn't go anywhere near the "new" top.  If mailnews isn't open, and I
open it with new messages, it doesn't go to the top.  It doesn't go to the
second most top message either (in win32).

Comment 5

[Chase Tingley]

Ok, reopening.  I'd sort of expect this to have a dup somewhere by now, but I
don't see one.

Comment 6

[Keyser Sose]

Marking NEW.

Comment 7

[Scott Tran (Wildcard)]

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

Comment 8

[Scott Tran (Wildcard)]

I'm assuming this happens on other windows platforms as well. Havent seen
anything to suggest otherwise.
OS->All

Comment 9

[basic]

if it is windows we keep it in windows not all, unless you can prove that it
happens on something other than windows.

Comment 10

[Peter Lockhart]

bug reported on Linux in bug 99466.
os -> all applies

Comment 11

[Scott Tran (Wildcard)]

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

Comment 12

[Scott Tran (Wildcard)]

Seth, 
Any progress on a patch for this ? This would surely increase the usability of
the mail client

Comment 13

[Ben Ruppel]

I just realized that this behavior is probably because of the behavior described
in but 80608.  That is, mozilla automatically scrolls to the first new message
(that is, the first beyond the old read messages).  If I'm in a newsgroup, with
date sorting descending (or ascending for that matter), I end up in the middle
of the list because mozilla goes to any new message in reply to an old topic or
whatever.  In any cases, it seems like these behaviors are intertwined.  Anyone
care to confirm?

Sidenote from bug 80608: "if I have date sorting set so that most recent
messages are at the top and I check my email, this behavior results in a
screenful of unread messages.  However, if I have some 50 messages, only the
first screenful are shown.  Now, say I start reading messages and I delete them
as I go(going top to bottom).  Deleting moves the focus down/scrolls the
messages up.  In this case, I could (and I have) gone through what seems to be
all of my messages, whereas there are a ton of unread messages off the top of
the screen.  So I guess the solution would be to have deleting messages follow
date sorting as well.  Seems logical, but totally bucks any trends that I've
seen.  Oy."

Comment 14

[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 15

[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 16

[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 17

[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 18

[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 19

[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 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]

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 22

[Karsten Düsterloh]

Moving the thread pane view while one is just reading mails would be plain confusing.