"Date" column in the thread pane

David Bienvenu bienvenu at davidbienvenu.org
Wed Dec 8 20:30:24 UTC 2010

The confusion here is that by default we're sorting by "thread date", which is not the same as the date of the first message in the thread, but rather the date of the 
newest message in the thread. You could also sort by thread id, which is not even displayed. This is done so that threads with new messages will bubble to the top (or 
bottom, depending on your sort order). But we're displaying the info for the first message in the thread.

What gmail and Postbox, iirc, do, is show the newest message in the thread as the top level message in the thread pane, when the thread is collapsed. If we did that, 
perhaps there would be less cognitive dissonance, since the date displayed would be the same as the default sort order when threaded.  The path of least resistance is 
probably to add an option to the nsMsgDBView class to do this, and have the Conversations extension set this option.  I'm happy to code that up, if that's what we decide to 
do.  The more general solution might be to add a lot more extensibility to the nsMsgDBView class to allow extensions to override all sorts of behavior like what to display 
for a given column or row.  I mention this just to bother Andrew :-)

The date value displayed in the view code already uses the received header.

- David

On 12/8/2010 9:32 AM, Jonathan Protzenko wrote:
> When in threaded view, the "date" column in the thread pane displays the date the thread started, not the date the latest message arrived. This is very confusing since 
> the sort order takes the date of the last message into account instead, which results in dates displayed not matching the sort order.
> I guess it was done for convenience reasons, such as having the property that the first line when the thread is expanded is also the same line for when the thread is 
> collapsed.
> So I was thinking about fixing this right away in nsMsgDbView.cpp instead of doing some ugly hack in Thunderbird Conversations, but I thought there might be good reasons 
> not to do so.
> Thoughts?
> jonathan
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning

More information about the tb-planning mailing list