Closed Bug 207766 Opened 21 years ago Closed 20 years ago

inside threadpane new threads are not correctly sorted by date when "view | threads | threads with unread" is selected

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 262319

People

(Reporter: whimboo, Assigned: sspitzer)

Details

Attachments

(3 files, 1 obsolete file)

corrupt display order of new threads
59.40 KB, image/jpeg
Details
Threadpane after newly-arrived messages
4.71 KB, image/png
Details
Same list of threads, on revisiting folder
2.86 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529

When viewing threads within the thread-pane as "view | threads | threads with
unread" new threads are not correctly inserted at the beginning or end of the
list. Instead you can see them at any point between the older threads. With a
reopen of the same group you can leave this problem. 

Probably it will also appear within the other thread-sorted modes.

Reproducible: Always

Steps to Reproduce:
1. change view to "view | threads | threads with unread"
2. mark all new messages as read
3. wait for a while and open newsgroup again when a lot of new postings arrived
4. new threads are not inserted at the beginning or end within the thread-list
but in the middle
5. effect doesn't appear when you reread the same group now. threads are sorted
correctly
Actual Results:  
New threads are not inserted correctly at hte beginning or end of the list.

Expected Results:  
New threads should be inserted at following positions:

Descending order - beginning of list
Ascending order - end of list

The same effect appears also with Mozilla 1.4 under Linux.
you are shure, you set the threads as search order?
Yes, otherwise i wouldn't have the arrangement of postings like you can see onto
my attachment. If this attachments isn't clear enought i can post another one
which will show more miss-sorted threads.
I don't know the criterion for the order of threads in a thread sort.  I thought 
it had to do with the date of either the oldest or newest unread message within 
the thread, but I just looked and found a newsgroup with threads sorting that 
didn't follow either of those.

See bug 72493 for the general problem of sorting a threaded view, altho I don't 
know if that bug is anywhere near resolution.
This bug appears only within the thread-view mode which is included since
version 1.4a or so. The message-view mode isn't affected!

I think it hasn't something to do with bug 72493 because the sort is working
after refreshing the actual group. The sort criteria is in my opinion correct.
But i think that Postings which opens a new thread are not recognized by first
time of opening the group. What operations run Mozilla during refresh? I don't
believe that there are any data-manipulations within the message list. It will
only refresh the view? 
I have another problem, which can be connected with this. Normally, my messages
are shown in threads and the threads are sorted by date. When new messages
arrive and I want to sort the messages by date the unread messages are not
displayed. After I put them back to threads and sort by date again, they are
visible.

My build is 2003070623 for Solaris 2.6 (but I could see this behaviour on
earlier builds already).

Following up on my comment 4: prior to the fix for bug 72493, threads were 
generally sorted by Order Received.  I believe this meant that, as Mozilla 
scanned the message list, every new thread encountered was placed at the end (or 
beginning) of the list.  Date order was not necessarily observed.

Now that 72493 is fixed, the user may select a sort order in addition to 
threading.  The threads are sorted according to the first item in the thread; so 
sorting by date puts the threads in date order of the top message in the thread. 
Usually, that means in the order the threads were started, unless displaying 
partially-read with Threads|Unread, or if the starting message has expired or 
been deleted.

There is (currently) no option to Sort Threads by Date of Most Recent Message.  
If there were, it would probably have to be a new, thread-only column (and would 
require a fix to bug 68903 for proper sorting).

Note that if the folder is being viewed as new messages come in, the new 
messages are not properly displayed as part of the existing threads; this is bug 
93426.

Henrik Skupin, what is your feeling about this bug?  Does the current 
sort-thread-by-date behavior satisfy your needs?
The sorting is ok and there isn't my problem. What i mean is opening a
newsgroup where new threads arrived. Perhaps my first attachment wasn't clear
enought. So i will add a new one where you can see the miss-order of new
threads in detail. 

I tried `Order received' and `date' but there is no difference how new threads
are displayed within the threadlist. Resorting the view corrects the problem.
Attachment #124637 - Attachment is obsolete: true
I'm sorry, Henrik, but I'm really having a hard time understanding what your
complaint is.  Attached is a screenshot of the threadpane in a newsgroup,
following your steps to reproduce:  Marked all messages as read, waited a
while, then executed Get New Messages.

All threads above the top of the list in the image had no new messages.
 - The two threads "Popups in Netscape 7.1..." and "Netscape 7.1 page
loading..." were in the list previously, and received new messages, so they are
shown with a 'new' green arrow flag, and the top-level message is underlined.
 - The thread "a problem with plugins" and the single message "!!!TEST!!!" were
completely new, and are shown after all the previously-displayed threads.
 - The thread "Re: Bug: localhost" had not been in the list of threads which
had been marked All Read, but messages from that thread had existed earlier. 
The new message from that thread is dated "6:43pm" which comes after the
"6:22pm" of the "!!!TEST!!!" thread.

It appears to me that these threads are all shown in an expected and consistent
ordering.  It is true that they are somewhat resorted after looking at another
group and then returning to the same group (addition image to follow) but I
don't see a problem with the original ordering shown in this image.
Both of these attachments are seen with   View|Threads|Threads with Unread  and
sorted per default (Order Received, ascending).
Ok, so what has changed in the ordering when you reopen/reload the newsgroup?
Nothing... it's just the same order like threads are listed. But why the threads
are now sorted correctly? This is really confusing! I don't understand this,
because i can't see any coherence between 'order received' and new postings
which are inserted into existing threads. So the thread list is not in the right
sequence. 

When i select a threadded view i also want's to have one. New threads should be
displayed at the beginning or the end of the threadlist depends on the selected
direction.

I hope it's clear now. Otherwise i have to make a better example.
In those attachments, the only thread that is in a different order is the "Re: 
Bug: localhost" thread.  That thread was not present when the newsgroup was 
originally marked All Read, so it was added to the end of the list.

However, on reentry to the group, it was sorted by the TOP message in the 
thread.  Since that thread's TOP message was older (had an earlier "Order 
received") than any of the other threads with new messages, it was placed first.

Henrik, you may be interested to know that bug 20385 has had a fix checked in; 
it's in 1.6b-1118 and subsequent builds.  If you sort threads by *date*, they 
are now ordered according to the most recent message in the thread.  

Be aware: this is *still* going to result in threads being re-ordered on 
re-entry to the group, depending on when messages arrive.

If that fix does what you wanted, I suggest marking this bug as a dupe of 20385.
Product: Browser → Seamonkey
Henrik, feel free to reopen if you believe this duplication is in error.

*** This bug has been marked as a duplicate of 262319 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
v.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: