when viewing a collapsed thread, date field should show timestamp of most recent message

NEW
Unassigned

Status

Thunderbird
Mail Window Front End
8 years ago
3 years ago

People

(Reporter: beltzner, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

STR:
1. View threaded, collapse all threads
2. Sort by date

Expected: date field shows date of most recent message
Actual: date filed shows date of first unread message

Note that Thunderbird already *sorts* based on the date of the most recent message, it just shows the date of the first recent unread message: http://grab.by/6Qoz
Correction:

Actual: date field shows date of earliest message in the thread
yes, agreed!
OS: Mac OS X → All
Hardware: x86 → All
Created attachment 524762 [details]
Expanded and collapsed thread with changing date.

Sadly, I can't ui-r my own stuff.  At least, not yet.  ;)

Later,
Blake.
Assignee: nobody → bwinton
Status: NEW → ASSIGNED
Attachment #524762 - Flags: ui-review?(clarkbw)
Created attachment 524767 [details] [diff] [review]
A first cut at the patch.

And the code that does the stuff.  I'm not totally happy about the duplication, so if you'ld rather I added an extra parameter or two to pass in the info I need, let me know, and I'll do that instead.

Thanks,
Blake.
Attachment #524767 - Flags: review?(bienvenu)

Comment 5

7 years ago
I think it would be most consistent to show all the fields of the newest message in the collapsed header, and not just the date. Thus, you'll see a row that represents a message. It's possible that you *don't* want to do this if we're not summarizing threads, or perhaps if we're not operating on collapsed threads. I.e., if clicking on the header in a collapsed thread is supposed to show just the message, it might want to be the real thread root, if that makes sense.

Updated

7 years ago
Attachment #524767 - Flags: review?(bienvenu)

Comment 6

7 years ago
There are a few bugs about related issues, e.g. bug 622779. Should we dupe to this one?
Comment on attachment 524762 [details]
Expanded and collapsed thread with changing date.

A thing of beauty!
Attachment #524762 - Flags: ui-review?(clarkbw) → ui-review+
(In reply to comment #6)
> There are a few bugs about related issues, e.g. bug 622779. Should we dupe to
> this one?

I would say no for that bug, since that seems like it'll be more work than the simple thing I'm doing here.  But I've added myself to that bug, and may work on it later.

(In reply to comment #5)
> I think it would be most consistent to show all the fields of the newest
> message in the collapsed header, and not just the date. Thus, you'll see a row
> that represents a message.

My only concern with that is that having a thread that starts with "Re: original subject" seems a little odd to me.

Ideally, I think that we want to display a new kind of thing, which lists some of the participants in the sender field, and the original subject, and most-recent date.  How does that sound to you?

> It's possible that you *don't* want to do this if
> we're not summarizing threads, or perhaps if we're not operating on collapsed
> threads. I.e., if clicking on the header in a collapsed thread is supposed to
> show just the message, it might want to be the real thread root, if that makes
> sense.

Clicking on the header in a collapsed thread (currently) shows the summary, which I'm pretty happy with, and don't expect us to change.  And I believe the bit of the code where I check for nsMsgMessageFlags::Elided makes sure that we're only operating on collapsed threads.  (I'm not entirely sure I understood what you were asking, but I hope that answers it.)

Thanks,
Blake.

Comment 9

7 years ago
(In reply to comment #8)
> (In reply to comment #6)
> 
> My only concern with that is that having a thread that starts with "Re:
> original subject" seems a little odd to me.
The subject can change in a thread, so you could end up with mismatched messages and subjects. Also, if you look at gmail, it will show the re: if the newest message has a re:
> 
> 
> Clicking on the header in a collapsed thread (currently) shows the summary,
> which I'm pretty happy with, and don't expect us to change.  And I believe the
> bit of the code where I check for nsMsgMessageFlags::Elided makes sure that
> we're only operating on collapsed threads.  

Not always - there's a hidden pref to turn it off, plus newsgroups don't get summarized. You can call this:

    mCommandUpdater->SummarizeSelection(&selectionSummarized);

to see if the thread is being summarized. In folderDisplay.js, this resolves to:

  get summarizeSelectionInFolder() {
    return gPrefBranch.getBoolPref("mail.operate_on_msgs_in_collapsed_threads") &&
      !(this.displayedFolder instanceof Components.interfaces.nsIMsgNewsFolder);

Comment 10

7 years ago
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #6)
> > 
> > My only concern with that is that having a thread that starts with "Re:
> > original subject" seems a little odd to me.
> The subject can change in a thread, so you could end up with mismatched
> messages and subjects. Also, if you look at gmail, it will show the re: if the
> newest message has a re:

I don't see this in Gmail. The only time I see "re:" is when the first message in the conversation has it.

Comment 11

7 years ago
(In reply to comment #10)
> 
> I don't see this in Gmail. The only time I see "re:" is when the first message
> in the conversation has it.

Perhaps the gmail UI is confusing me - wouldn't be the first time. In any case, it's trivial to display the subject w/o Re: because we store the subject w/o the re: in the msg hdr, and stick it back on when displaying the subject.
I'm not really working on these, so I'm freeing them up for a community member to take.
(Filter on [ossifrage] to delete all the notifications.)
Assignee: bwinton → nobody
Status: ASSIGNED → NEW

Comment 13

3 years ago
Is this issue still on the docket?  I vote for the collapsed item to show all fields from the newest message, especially date, but ideally all fields.
You need to log in before you can comment on or make changes to this bug.