Closed Bug 397928 Opened 17 years ago Closed 16 years ago

(pref unthreads=True): Threading via column header forces Sort by "Order Received", should not change

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird 3

People

(Reporter: bugzilla, Assigned: mkmelin)

Details

Attachments

(2 files, 2 obsolete files)

Steps to reproduce:

- Pull down Thunderbird thread page column picker and choose "Order Received", 
  so you can see 
- Click the header of the thread column to sort by thread

Expected: No change of sort occurs.  If you want to sort by date, just click on the Date header.  This is mind-bogglingly obvious.

Actual: Order Received column acquires "sort arrow"; Thunderbird sorts the threads in order of "lowest order-received number in thread".
Attached patch Fix v1.0 (obsolete) — Splinter Review
Submitting fix/patch.
Attachment #282725 - Flags: superreview?(mnyromyr)
Attachment #282725 - Flags: review?(bienvenu)
Attachment #282725 - Flags: superreview?(mnyromyr)
Attachment #282725 - Flags: superreview?(bienvenu)
Attachment #282725 - Flags: review?(mnyromyr)
Attachment #282725 - Flags: review?(bienvenu)
I probably fail to see the point, but why don't you just set mailnews.thread_pane_column_unthreads=false if you want its behaviour?
Thx, Karsten, I've been meaning to say that as well. I suspect the answer has to do somehow with mimic'ing Outlook Express behavior, and paving the way for the received column somehow...
Maybe I'm just misunderstanding the convoluted pref name.  What is 'unthreads' supposed to do, exactly?
if you're in threaded mode, and you click on a column, e.g., the subject column, it takes you out of threaded mode into flat sorted by subject mode.

If unthreads is set to false, clicking on the subject column while in threaded mode sorts all the threads by their subject.
Right, so I didn't misunderstand.  There's nothing inherent to unthreads=true that should give the Date column some preference for sorting.
So, I meditated about this for a while and, actually, I agree with Jeremy here. In fact, I'm using mailnews.thread_pane_column_unthreads=false ever since this pref was introduced...

IMO, this pref should only distinguish between two kinds of behaviour:
(a) 
  (1) Clicking the unthreaded icon changes the view to threaded, without 
      changing the actual sort type and order. Thus, the threads will be
      sorted by whatever column had the sort before.
  (2) Clicking the threaded icon changes the view to unthreaded, without 
      changing the actual sort type and order. Thus, the messages will be
      sorted by whatever column had the sort before.
  (3) Clicking any other column header will sort the threadpane by it, either
      the threads or the messages, depending upon threaded on/off.
(b)
  (1) Clicking the unthreaded icon changes the view to threaded, without 
      changing the actual sort type and order. Thus, the threads will be
      sorted by whatever column had the sort before.
  (2) Clicking the threaded icon toggles the sort direction of the current 
      sort, without changing it or threaded mode otherwise.
  (3) Clicking any other column header will turn off threaded mode and sort
      the messages by it.

Neil, what do you think?
Originally, i.e. three years ago, threaded mode was a distinct sort order of its own. Bug 219620 made it possible to use the menus to change the sort order and turn threading on or off independently, however the column headers still emulated the old behaviour for backward compatibility. Bug 72493 then added the pref so that the column headers could also control threading and sorting independently, although the pref still defaults to the historic behaviour.
That doesn't make that behaviour any more logical or useful.
We should correct it.
Dontcha know the Thunderbird motto?  "If it might mean old users have to experience change, it shouldn't be done."

Perhaps that attitude will disappear with Bienvenu and Mscott gone.
(In reply to comment #9)
>That doesn't make that behaviour any more logical or useful.
>We should correct it.
Isn't that the point of toggling the pref?
(In reply to comment #11)
> Isn't that the point of toggling the pref?

Well, the pref doesn't just toggle the behaviour of when to toggle threaded<->unthreaded, it also changes the sort.
If that weird sorting is indeed the intended behaviour, we should probably set the pref's default to false... (That way, people used to it can still get it and new ones won't miss it anyway.)
(In reply to comment #12)
>we should probably set the pref's default to false...
Fine by me.
(In reply to comment #11)
> Isn't that the point of toggling the pref?

Karsten's comment 7 -- which would be easier to understand if (a) and (b) had been replaced by (unthreads=false) and (unthreads=true) -- actually proposes a change of behavior for the unthreads=true case: it turns off the change in sort criterion that currently accompanies clicking the Thread column header.

I am fully in favor of the default value of that preference being changed.  I have seen bugs reported and questions in the newsgroup about the current default behavior which is, IMO, highly unintuitive.


I find comment 10 far from reality, and tastelessly snarky.
David, would switching the default be fine for TB?
Attachment #289385 - Flags: review?(bienvenu)
personally, I'd hate changing the default. But if SeaMonkey wants to do that, I think that's fine to do it in your own .js file, or change mailnews.js to set it to false, but override it in all-thunderbird.js.
Attachment #289385 - Attachment is obsolete: true
Attachment #289529 - Flags: superreview?(neil)
Attachment #289529 - Flags: review?(bienvenu)
Attachment #289385 - Flags: review?(bienvenu)
Comment on attachment 289529 [details] [diff] [review]
switch pref default setting to false, keep TB defaulting to true

thx, Karsten.
Attachment #289529 - Flags: review?(bienvenu) → review+
David, do you think that the current behavior is the right one?  I'm not sure I understand all the subtleties, but there seems at least consensus on this thread that the current behavior is confusing w/ the current semi-orthogonal relationship between threading and sorting.

I've gotten lots of personal comments about threading in Tb being "broken", and this bug feels like it's poking at some of the issues, although somewhat obliquely.  Maybe there's a better bug to discuss this.
I find the current behavior to be the most useful one, but that's because I frequently go between threaded mode, and sorted flat by date mode, and I never want to sort threads by anything other than date. So with the current behavior, I can do that with single clicks on column headers. With the proposed behavior, I'd have to navigate menus and sub-menus...For people who stay in threaded mode all the time, and want to sort threads by different criteria, currently they have to use the menus, which is inconvenient for them. 

If we switch the default, I suspect we'll annoy a fairly large number of users, but that's just a guess.

If people are going to say "threading is broken", they need to be a bit more specific...the main complaints I hear about threading are that we don't create a dummy header to replace missing messages, and that we don't have twisties on sub-threads.
re: "Threading is broken" comments, I agree, that level of complaint isn't useful. What people have referred to when I take the time to dig a bit deeper is that in a date-sorted view, threads (IIRC) are ordered based on the first email in a thread, not the last one -- or at least not by the date received (which I suspect isn't a real field). 

I suspect those comments come from people trying to emulate the experience of gmail or mail.app, where "new threads" bubble up to the top/bottom, which AFAICT is hard to do in Tb today w/o an extension or a pref tweak.

I wouldn't be surprised if this bug (blending "received order" and thread view) is somehow tied to that higher-level need.

Back to this bug: 

David -- for your use case, which I share, doesn't clicking on the thread mode indicator toggle with the pref _on_ work?  It seems to work for me.

Attachment #289529 - Flags: superreview?(neil) → superreview+
Comment on attachment 289529 [details] [diff] [review]
switch pref default setting to false, keep TB defaulting to true

Landed on trunk.

davida: the pref's name is somewhat misleading (I  also misunderstood it until David explained *g*), the name means "any click on a column header other than the thread column will unthread the view".
Comment on attachment 282725 [details] [diff] [review]
Fix v1.0

Clearing review request, since this approach apparently is not going to happen. Feel free to rerequest if things change.
Attachment #282725 - Flags: review?(mnyromyr)
(In reply to comment #22)
> "any click on a column header other than the thread column will
> unthread the view". 

And that, far more than the "change criteria to Order Received when switching to Threaded" is the part of this that so severely violates the Principle of Least Astonishment.  All the questions that I've answered regarding this issue have been around this behavior.

David, with all due respect (and I hope you realize that respect is genuine):
you are *so* wrong.  I can understand why you like the current default behavior, but I can't understand why you won't concede that it's more confusing to novice users.


Incidentally, bug 369620 has David's patch, approved by Scott but still not checked in, which changes the "unthreaded=true" click-on-Thread-header behavior so that it sorts the threads by date, rather than Order Received.
(In reply to comment #24)
> David, with all due respect (and I hope you realize that respect is genuine):
> you are *so* wrong.  I can understand why you like the current default
> behavior, but I can't understand why you won't concede that it's more confusing
> to novice users.

Mike,

Don't bother trying to reason with him.  It only increases his arrogance.
I don't think I ever argued that the current behavior isn't more confusing to novice users - I was more concerned with existing users.  We can try changing the default and see what happens...
(In reply to comment #25)
Jeremy, your comments lately are highly inadequate. They'll just upset folks and won't help your cause in any way. Please keep this out of Bugzilla. 
Thank you.
David,

You know I've always argued that improving Thunderbird is more important than keeping things the same for existing users, as long as existing users can change a pref to get that functionality back.  Some may complain, but I say that's OK if we're improving things.
David, since it sounds like you're ok with it (comment #26), I think it's worth trying out. This sets the pref to false for thunderbird too.
Attachment #315560 - Flags: superreview?(bienvenu)
Attachment #315560 - Flags: review?(bienvenu)
Attachment #315560 - Flags: superreview?(bienvenu)
Attachment #315560 - Flags: superreview+
Attachment #315560 - Flags: review?(bienvenu)
Attachment #315560 - Flags: review+
Thx, fix checked in

Checking in mailnews/mailnews.js;
/cvsroot/mozilla/mailnews/mailnews.js,v  <--  mailnews.js
new revision: 3.311; previous revision: 3.310
done
Checking in mail/app/profile/all-thunderbird.js;
/cvsroot/mozilla/mail/app/profile/all-thunderbird.js,v  <--  all-thunderbird.js
new revision: 1.111; previous revision: 1.110
done
Assignee: nobody → mkmelin+mozilla
Target Milestone: --- → Thunderbird 3
->FIXED
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Attachment #282725 - Attachment is obsolete: true
Attachment #282725 - Flags: superreview?(bienvenu)
I can verify that the default on the pref has been changed; thanks, I think that was a good thing to do.  (Note that Seamonkey has a UI for this in Preferences, but I don't think that's necessary for TB now that the default behavior is the simpler one.)

The behavior originally reported in this bug is not implemented; however, with the recent checkin at bug 369620, when you have the pref=true and click the Thread column header, the new sort order is by date.  (Which I also think was a good thing to do.)
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: