199217 - confusion of sort by thread when switching from desc. sorted flat view

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Christian Eyrich]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.4a) Gecko/20030323
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.4a) Gecko/20030323

A little hard to describe.
Do a non-thread sort (like subject, sender, date a.s.o) in desending order.
Click on thread-col heading.
Mail list will be sorted by thread but m_sortOrder won't be set to the new
sortOrder. It will be set to sortOrder not until reverse sorted by thread.

This results in the asc-icon for thread-col heading will show up if sorted if
the thread is sorted descending and vice versa.

Normaly this malconduct can't be seen since the thread-col has the same icon for
ascending and descending sorting order. But I noticed it while working on bug
195832.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Christian Eyrich]

Attachment: proposed patch

Set m_sortOrder to new sortOrder after applying sort.

Comment 2

[Mike Cowperthwaite]

Your description is a little hard to follow, but I think I've figured it out.
I think having Bug 199477 as a separate bug makes this even harder to follow;
they seem to be very closely related.

Here is my description of the problem I see going from Flat to Threaded
sorting:

When a new sort criterion is chosen, it should force to "Ascending" order.
Flat-sort criteria do this; however, when Sort by|Thread is selected, the
order used is the same as when Sort by Thread was *last* used.  (This is
Bug 199477.)

If this new sort order is different from the sort order used for the flat
criterion, then the UI displays the sort order in reverse:

  by Thread (Ascending) => by Date (Descending) => by Thread  yields:
    messages sorted ascending by thread, but View|Sort by|Descending is checked

  by Thread (Descending) => by Sender (Ascending) => by Thread  yields:
    messages sorted descending by thread, but View|Sort by|Ascending is checked

Once the UI selection is reversed, it continues to be reversed: change the menu
selection from Ascending to Descending, and the descending threads resort
in ascending order.

I can confirm this behavior in 1.4b:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030408

Since my report now contains the essence of this bug and 199477, I suggest
you mark that as a duplicate of this one, OK?

Comment 3

[Christian Eyrich]

Hm, both problems result in confustion about thread sorting, yes. But since
there are two different points to fix, I'm not really sure if duping 199477 is
the best.

Point 1 is that the indicators show what they should (ascending when changing
from one sort type to another) (this bug).
Point 2 is to fix the behaviour of thread sorting itself (bug 199477).

Comment 4

[Christian Eyrich]

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

Comment 5

[Mike Cowperthwaite]

Christian, you may have noticed that the sorting behavior has changed a lot, due 
to the fix for bug 72493.  I think that the problem described in this bug no 
longer occurs, altho it's a little hard to be sure because "Sort by |Thread" 
behaves somewhat differently than it used to; see also bug 219620.

Comment 6

[Christian Eyrich]

I didn't inspect the new behaviour before. Now I did, and I'm still confused.

> I think that the problem described in this bug no longer occurs

I don't think so. The problem can't be visualized by the patch from bug 195832.
This seems because of another change from patch for bug 72493.
But m_sortOrder is still not set to sortOrder.


To this the summary from bug 199477 is still true too. "Thread sorting isn't
always ascending when coming from flat sort". Comming from flat sort to thread
sort by clicking on the ThreadCol head sorts by thread in the order the previous
flat sort had.

So
ascending sender sort -> ascending thread sort
descending sender sort -> descending thread sort
but
ascending sender sort -> ascending subject (or more exact !thread) sort
descending sender sort -> ascending subject (or more exact !thread) sort

Comment 7

[Mike Cowperthwaite]

Christian, I am seeing slightly different behavior now than described in 
comment 2.

Following are some test results using
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031003
This version has the fix for bug 72493, plus followup fixes for bug 217031 and 
bug 218656.

It is necessary now to track actions of View|SortBy|Thread (VST) vs.
View|Messages|Threaded (VMT), as these two currently behave differently.
(VST is equivalent to clicking on the Thread column header.)
Also, it is helpful to display the Order Received column.

Repeating the tests in comment 2:
(1)  VST (sort by Thread, Ascending) 
Menu state: Order Received, Ascending
Order Received column: NO SORT ICON shown.
     => VMT (return to flat)
Menu state: Order Received, Ascending
Order Received column: Ascending sort arrow icon.
     => Sort by Date (Descending) => VST:
Messages are threaded, sorted by Order Received, Descending.
Sort menu state is Order Received, Descending.  
Order Received column: NO SORT ICON shown.

(2)  VST (by Thread, Ascending) => VMT (return to flat)
     => Sort by Date (Descending) => VMT:
messages are threaded, sorted by Date, Descending.
Sort menu state is Date, Descending.  
Date column has ASCENDING sort icon (arrow pointing down)

(3)  VST => View Sort Descending
Menu state: Order Received, Descending
Order Received column: Descending sort icon.
     => VMT (return to flat) 
Menu state: Order Received, Descending
Order Received column: ASCENDING sort icon.
     => Sort by Sender (Ascending) => VST  yields:
Messages are threaded, sorted by Order Received, Descending.
Sort menu state is Order Received, Descending.  
Order Received column: NO SORT ICON shown.

(4)  VST => View Sort Descending => VMT (return to flat)
     => Sort by Sender (Ascending) => VMT  yields:
messages are threaded, sorted by Sender, Ascending.
Sort menu state is Sender, Ascending.
Sender column: Ascending sort icon

In these cases, the *menu* state always agrees with the actual sorting (which 
wasn't true before, a problem I described in comment 2).  But the *sort icon* 
state can have various problems depending on the sequence of operations; and I 
think that's what you originally intended the bug for.

Specifically:
One symptom is that whenever View|Sort By|Thread is selected, the threads are 
sorted by Order Received, Ascending; but the Order Received column does not show 
an Ascending sort-arrow icon, until/unless the View|Sort By|Order Received, or 
Ascending, or Descending menu is selected, or until the Order Received column or 
Thread column is clicked.
(I first discovered this while testing for bug 219787.)

The other symptom is that if View|Messages|Threaded is selected, and the 
threaded sort is Descending, the actual sort order is not affected, but the 
column sort icon is always shown Ascending.  This is true whether VMT is used to 
turn threading on or to turn it off.

In addition, you are correct about the symptom from bug 199477: 
View|Sort By|Thread (still) does not (always) force the sort order to Ascending: 
if VST is selected from an unthreaded, Descending view, then the sort order is 
maintained as Descending.  If VST is selected from a threaded, Descending view, 
the order is reverted to Ascending.

Can you update your patch to address all three of these symptoms?

Comment 8

[Christian Eyrich]

No Mike, I can't update my patch - I simply don't have the knowledge.
The first "patch" was quite simple and I stumpled over it more by chance than by
engineering.

Comment 9

[Mike Cowperthwaite]

Christian, the patch for bug 219787 is in place, for 1.6b nightlies; and it 
fixes the problems I described in comment 7 as well.  Please comment as to 
whether this bug should be resolved or not.

However, I believe that this fix complicates your goal of having different icons 
for ascending vs. descending in the thread column (bug 195832) -- the 'byThread' 
sort ordering is now never used, in favor of the 'byId' one.
(Note that ID == Order Received)

Comment 10

[Mike Cowperthwaite]

Christian Eyrich, when you get a chance to test Mozilla 1.6, please comment here 
on what you wish to do with this bug.

Comment 11

[Christian Eyrich]

I clicked around a lot now and couldn't (re-)produce any sort direction error.
Though I didn't look at it in debugger or so, I think it has been fixed while
working on some of the other sort-bugs.

Comment 12

[Mike Cowperthwaite]

v fix -- see bug 219787.