135964 - View -> Messages Change Deselects Displayed Message

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Felix Miata]

2002040508 (not new)
OS/2 (probably not specific)
Modern; Search Box Off

Steps to reproduce:
1-Select a large newsgroup folder in default three pane view
2-Set view -> messages to either all or unread
3-Select a message
4-Set view -> messages to all if unread, or unread if all
5-GoTo 3 or GoTo 4 (optional)

Actual Behavior:
1-Content of previously selected message remains in view
2-No message is selected in header pane
3-Header pane is scrolled away from displayed message header (typically to top)

Expected Behavior (like Netscape 4.x)
1-Displayed message remains selected in header pane
2-Header pane shows currently selected message
3-Content of selected message remains in body pane

Comment 1

[laurel]

I believe we may already have an older bug about this... will look.

Comment 2

[laurel]

didn't locate older bug

Comment 3

[Mike Kaply [:mkaply]]

Not OS/2 specific

Comment 4

[Mike Cowperthwaite]

What is the expected behavior if the selected message is not part of the new 
view?

Comment 5

[Felix Miata]

I don't understand the question in comment 4. Be that as it may. Expected
behavior is Netscape 4 behavior as described in comment 0.

Actual behavior as described in comment 0 is mostly not applicable as of W32
build 2003050211.

Following current behavior description is with sort set to subject ascending.

Switching from unread to all now retains the message selection in the headers
pane and continues to display that message body. IOW, switching from unread to
all is now WFM.

Switching from all to unread continues to deselect the currently displayed
message. Also it scrolls the headers pane to the top, and blanks the body pane,
regardless whether the unread status marker on the currently displayed message
is set to unread.

Comment 6

[Mike Cowperthwaite]

Comment 4's question appears quite clear to me, but I will expand on it: suppose 
you are viewing All, and select a message that is Read.  When you switch to an 
Unread view, that message should no longer be part of the view; therefore, it 
should no longer appear in the list of messages; and therefore, it cannot remain 
selected.  In this case, deselecting the message and blanking the message pane 
seems a reasonable thing for the program to do.

The symptom you describe in the last paragraph of comment 5, as it happens, 
occurs (in 1.4b-0516) even if the currently viewed message has been explicitly 
marked as Unread, which I think qualifies as a bug.

Comment 7

[Felix Miata]

> When you switch to an  Unread view, that message should no longer be part of
the view...

Wrong. The currently selected message should *never* be deselected before
another message or folder is selected. That's the crux of this bug.

When I go to a menu to change the *headers pane* view, I am not requesting a
change in the *message pane* view. A change in the message pane content should
not take place until selecting another message or folder, just as it is in
Netscape 4. Until I do select another message or folder, nothing in the message
pane should change, just as it is in Netscape 4. Apparently a change in headers
pane view in Netscape 4 treats the currently selected message as unread. Mozilla
should do the same. Just because the message is displayed and marked read in the
headers pane doesn't mean I'm done with it.

Here's an example of the utility of the Netscape 4 behavior: 
1-Select a folder
2-Set view to all (which along with . . .)
3-Sort on date (. . . allows me to find last message, whether read or unread)
4-Select last message
5-Set view to unread
6-Sort on thread

Result: I still see the selected message, and in the headers pane the message's
header row is selected, and displayed in its position in the thread, showing me
when the thread started, whether read or not.

Comment 8

[Mike Cowperthwaite]

Bug 191787 appears very similar to this.  Since that bug has been granted 
nsbeta+ (altho languishing), perhaps you'd like to dupe this to that.

Comment 9

[Felix Miata]

*** This bug has been marked as a duplicate of 191787 ***

Comment 10

[Felix Miata]

Got it backwards

Comment 11

[Felix Miata]

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

Comment 12

[Robert Kaiser]

MASS-CHANGE:
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 13

[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