118508 - "N" goes to next unread by recieved order instead of folder message sort order

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Andrew Brecher]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122106

N)ext unread command sometimes skips around.  I have not figured out the
pattern, and it works correctly about 90-95% of the time.  I use threaded
messaging with threads sorted by date (oldest to newest).  As soon as I figure
out anything I'll post another comment.  

Reproducible: Sometimes
Steps to Reproduce:
1.Open window with newgroup post
2.Press 'n'
3.

Comment 1

[Tuukka Tolvanen (sp3000)]

By "skips" do you mean it doesn't display the message? Reporter, take a look at
bug 59638; if this bug is the same as bug 59638, please mark this as a
duplicate. Thanks

Comment 2

[David A. Cobb]

I'm seeing this also on Win98se Moz 2002-03-28-03, pls. verify not platform
specific.

Occasionally, it doesn't move at all.

Comment 3

[Duane Chamblee]

I have this problem when using the "next" button or the N key...
build 2002050609 OS/2
Using a separate message window (no preview in message center), when I hit next
in a newsgroup, the next unread message (from the top of the message list) is
read instead of the next unread in the current thread...
I sort my message listby reverse date & threaded (two clicks on the thread
column header)

Comment 4

[Greg K.]

Setting All/All per Comment #2. Also, Andrew, David, and Duane, please respond to Comment #1.

Comment 5

[David A. Cobb]

Re: "Also, Andrew, David, and Duane, please respond to Comment #1."
1) Not a dupe.  I've noticed the Bug#59638 behavior; this applies one also
within an open folder -- not simply at the last unread.

2) Not exclusive to news, also problem in mail.

3) It /appears/ that "Next" may be following the order-of-receipt as, I imagine,
does the MBX file itself -- ignoring the sorted/threaded setting.  *Possibly a
damaged or missing .msf?*

Comment 6

[Ian Neal]

Looking at comment #5 part 3 maybe this is related to bug 65962 ?

Comment 7

[David A. Cobb]

Re: Comment#6 --

  It's a dupe for Bug#69562 only as regards the summary description.  As I read
it, Bug#69562 requests exactly the OPPOSITE behavior to what is expected here --
*see my comment there*.
  I don't know the community procedure for this -- we seem to have two
diametrically opposed requests, how do we decide what is the correct desired
behavior?  [ Other than writing a string of 300 comments as appears elsewhere ]

Comment 8

[Ian Neal]

Perhaps via a preference that switches between the two behaviours?

Comment 9

[Andrew Brecher]

Doesn't look like a conflict to me.  N)ext should go in the direction of the
sorting order (65962), starting at the currently open (or highlighted) message
(118508).  [If in a thread, go to next message listed in thread, only use the
direction of sorting order to determine which thread to go to when at the end of
the current one.]

Re my careless use of the word "skips".  I meant only that the N)ext message
displayed is not actually the next message (in the thread, in the sort order). 
Usually it is the first message received.

Comment 10

[Arthur]

Confirming based on comments and in order to make it show up in quick searches.

Comment 11

[Mike Cowperthwaite]

Andrew Brecher (and others): is this bug still present in current builds of 
Mozilla?  I've never seen this behavior myself, but I've only been using 
threaded view since I started using Mozilla for newsgroups, beginning with 1.3.

Comment 12

[Mike Cowperthwaite]

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

Comment 13

[Mike Cowperthwaite]

Is this bug still a problem for anyone, or should it be resolved WFM?

Comment 14

[Mike Cowperthwaite]

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

Comment 15

[Mike Cowperthwaite]

=>WFM, nobody reading this is still complaining about it.  If the problem does 
reoccur, feel free to reopen this.

Comment 16

[David A. Cobb]

MORE ACCURATE STATUS: DUPLICATE http://bugzilla.mozilla.org/show_bug.cgi?id=65962
I see Bugzilla is "improved" so I can't just re-open this one.
Whatever else, it still DOES NOT WORK for me

Comment 17

[Mike Cowperthwaite]

OK, I agree with the dupe.

Comment 18

[Mike Cowperthwaite]

Marking as dupe, as suggested.  Perhaps I don't understand the problem well 
enough, but I've never seen N cause skipping around.

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

Comment 19

[Mike Cowperthwaite]

Reopening -- sorry for the noise, but on reexamination, I don't think the 
duplication is correct.  That bug (as originally reported, anyway) is requesting 
reverse-traversal of the list in positive date order, when the list has been 
sorted newest-first.

Comment 20

[Mike Cowperthwaite]

Attachment: mbox file containing one thread

I found a situation where I can see the 'jumping around' altho I think it's in
a sensible form.  Integrate this attachment into your mail (close Mozilla, copy
the file into a mail account's directory, or into Local Folders; then reopen
Mozilla -- these messages will appear in folder 'xthread').

Open the folder and view as Flat, by Date (or Order Received).	Double-click on
the first message to open it into a standalone message window.	NOW, sort by
thread; then return the focus to the standalone window.  As you type 'N', the
messages will be traversed in the original order, 'jumping around' within the
thread.  (This is easy to see if the messages are all marked Unread before
proceeding.)

Repeat this experiment: Close the standalone, mark all messages Unread; folder
should still be sorted by thread.  Double-click the first message, then type
'N' -- messages are traversed in Thread order, as they appear in the list.

Does this procedure explain the problems some people have been seeing?

Comment 21

[David A. Cobb]

Well, I don't have to do any procedure to see it.  As an example, I keep my
bugzilla feedback in a folder viewed in "Threaded" order so I can follow the
progress.  

At least when the messages are some-read, some-unread, ALL the navigation keys
'N', 'F', 'B', follow some order other than the displayed folder order.  I see
this even  without making any change while the standalone message pane is open.
 It appears that navigation is simply following the order of the messages in the
mailbox file.  

To do this right, the standalone message pane needs to remain tied to its
"parent" view - the message list from which it was initiated.  Whether it then
navigates by returning to the message-list code with some indication of the
desired movement, or calls some method in the message-list object to advance the
"cursor" - I haven't dug into the code yet.

Comment 22

[David A. Cobb]

This is even more inconvenient than I thought!

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031116
Firebird/0.7+

If the 3-pane view has the threads collapsed, then "F" / "B" in stand-alone do
not move down the thread at all.  "F" moves from the head of one thread to the
head of the next, then (at end) it doesn't move at all.

While I'm pushing for following the ordered-ness of the "parent" 3-pane,
ignoring the collapsed thread is just plain silly!

Comment 23

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

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

[Karsten Düsterloh]

This is WFM as per description/summary. If any of the issues mentioned in various comments does still appear (although AFAICS they're either gone or invalid), please file a new bug.