289411 - e-mail tag is not visible when thread is collapsed

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, enhancement)

Description

[Torben Putkonen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1
Build Identifier: version 1.0.2-1.3.1 (20050323)

It is impossible to see whether or not a collapsed thread contains e-mails that
have been assigned special labels.

Reproducible: Always

Steps to Reproduce:
1. Set message list to threaded mode.
2. Expand one thread, pick an e-mail from the thread (not the root of the thread)
3. Label that e-mail as "important" (right click -> label -> important)
4. Collapse the thread.
Actual Results:  
The collapsed thread looks normal.

Expected Results:  
The collapsed thread should somehow indicate that it contains an e-mail that has
been labelled important.

Comment 1

[Tuukka Tolvanen (sp3000)]

seamonkey bug 122908, also bug 185801

Comment 2

[Wayne Mery (:wsmwk)]

confirming

Comment 4

[Tuukka Tolvanen (sp3000)]

Something like a compact stack of tag-colored blobs ( ascii-art: CCCO ) comes to mind, which could also be used to indicate several tags on an individual message. A more compact representation of the availabe Tags column, really, with merging over a collapsed thread.

Comment 5

[Wayne Mery (:wsmwk)]

duping to older bug

Comment 6

[Tuukka Tolvanen (sp3000)]

nah, bug 135472 is about showing tag colors in the folder pane -- I've occasionally been thinking that would be nice, but it sounds like it could be more distracting, so while similar, perhaps better not tie them together

Comment 7

[Robin Message]

Attachment: Patch to make collapsed threads highlight with the highest priority tag in thread

This patch causes collapsed (elided) threads to be highlighted with the highest priority tag (keyword) that is used anywhere in the thread.
This is my first patch; I'm not sure about the approach, the changes or anything, but this patch does fix the behaviour and I believe it is more useful than the current view on collapsed threads, which just shows the highest priority tag for the root message.

Comment 8

[David :Bienvenu]

Comment on attachment 548410 [details] [diff] [review]
Patch to make collapsed threads highlight with the highest priority tag in thread

You'll end up with a lot of duplicates in keywords w/ this approach.

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 548410 [details] [diff] [review]
Patch to make collapsed threads highlight with the highest priority tag in thread

Bienvenu is the ideal person to review changes to nsMsgDBView.  In this case, it's preferable to get UX approval before pursuing the change further to confirm that the change to the user interface would be a desired change.

Comment 10

[Robin Message]

(In reply to comment #8)
> Comment on attachment 548410 [details] [diff] [review] [review]
> Patch to make collapsed threads highlight with the highest priority tag in
> thread
> 
> You'll end up with a lot of duplicates in keywords w/ this approach.

Thanks for looking at this. As far as I could see, the only thing that these keywords is used for is to pick the highest priority keyword, so duplicates are irrelevant (in fact, making a deduplicated list would be more work than just relying on the highest priority keyword being picked.)

(The only use of the return value of FetchKeywords is to call AppendKeywordProperties on lines 1167 and 1252. GetTopKey is called on the keyword list in AppendKeywordProperties on line 350.)

Comment 11

[Robin Message]

(In reply to comment #9)
> Comment on attachment 548410 [details] [diff] [review] [review]
> Patch to make collapsed threads highlight with the highest priority tag in
> thread
> 
> Bienvenu is the ideal person to review changes to nsMsgDBView.  In this
> case, it's preferable to get UX approval before pursuing the change further
> to confirm that the change to the user interface would be a desired change.

Thanks, he's already commented so that's great! I can't see a way to submit a ui-review on that patch now so I'll email  Bryan Clark directly.

Comment 12

[David :Bienvenu]

(In reply to comment #11)
.
> 
> Thanks, he's already commented so that's great! I can't see a way to submit
> a ui-review on that patch now so I'll email  Bryan Clark directly.

Blake (bwinton) does UI reviews now, not Bryan.

Comment 13

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 548410 [details] [diff] [review]
Patch to make collapsed threads highlight with the highest priority tag in thread

I like the interactions that happen here, but it's far slower to update the tags on the message summary than I would like.

So, I guess ui-r=me, but if we can make it faster that would be way, way better.

Thanks,
Blake.

Comment 14

[David :Bienvenu]

(In reply to comment #13)
> 
> I like the interactions that happen here, but it's far slower to update the
> tags on the message summary than I would like.

How many messages are in your threads? By update, do you mean display? Our tag/keyword handling code is probably not as fast as it could be, but it didn't used to have to deal with a lot of duplicate keywords...I'm a little surprised you'd notice it in normal use.

Comment 15

[Blake Winton (:bwinton) (:☕️)]

Three, and yes.  ;)

(The row displays in the correct colour just fine, it's only updating the message summary that's noticeably slow.  Maybe that's a different bug I'm running into?)

Comment 16

[David :Bienvenu]

(In reply to comment #15)
> Three, and yes.  ;)
> 
> (The row displays in the correct colour just fine, it's only updating the
> message summary that's noticeably slow.  Maybe that's a different bug I'm
> running into?)

I don't think this patch could affect that.

Comment 17

[Jim Porter (:squib)]

(In reply to comment #15)
> (The row displays in the correct colour just fine, it's only updating the
> message summary that's noticeably slow.  Maybe that's a different bug I'm
> running into?)

That's because the message summary is handled via gloda, and gloda takes a second or two to index changes to messages. Theoretically, it'd be possible to listen for changes to tags, read status, etc with regular folder listeners, but I'm not sure we'd want to spend the time necessary to do that. To be fair, I've got most of the code to do this already in Mail Summaries, so maybe it wouldn't be too hard to port over.

Comment 18

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 548410 [details] [diff] [review]
Patch to make collapsed threads highlight with the highest priority tag in thread

(Since it's got ui-r+, I'll ask Bienvenu to review the code itself.  Normally this would be your job, Robin, but I don't mind helping out this time.  :)

Comment 19

[David :Bienvenu]

Attachment: get rid of extra copying of keywords, move comptrs outside the loop

I tweaked the previous patch a little. This is what I'll land. Thx for the patch.

Comment 20

[David :Bienvenu]

actually, I forgot - it doesn't really make sense to call FetchThreadKeywords if it's not a collapsed thread, so that logic belongs outside that function, I think. I'll tweak it a bit more before landing.

Comment 21

[David :Bienvenu]

Attachment: actually, just change method name.

this is what I landed - http://hg.mozilla.org/comm-central/rev/e8423ae0f0ac

Comment 22

[David :Bienvenu]

fix checked in, thx for working on this, Robin.

Comment 23

[RDL]

Please advice on how original behaviour may be obtained where users have chosen to use tags and their colours to distinguish eg 'input' and 'output'. Originally use of labels to classify mails rather than prioritize them was an obvious possibility and nowhere discouraged.

For me, the current effect of your change is to show colours indicating that  all collapsed threads which I originated as instead apparently originating from a respondent. Changing round my labels would invert the problem but not cure it.

Of course the 'From' field shows the truth but the colour coding up to now gave me an immediately visible indicator of 'my' threads and those started by others. Keeping the threads expanded to provide the picture leads to a confusing picture.

I really don't want to have to raise a new bug report just to (eventually and only perhaps) be able to regain a simple, natural and helpful technique.

Is there a preference to prevent the new behaviour, or can you suggest an alternative way to obtain the previous picture?

Comment 24

[Jan]

See Bug 718279 for a request to make this configurable. Like RDL said, this totally breaks some use cases of tags.

Comment 25

[Maxim Makarenko]

I would like to remind about the issue which is still open for 14 months now. I personally still has to use 8.0 version of Thunderbird, this is ridiculous...

Comment 26

[Magnus Melin [:mkmelin]]

Maxim: this issue is closed (RESOLEVD FIXED as of thunderbird 9.)

Comment 27

[Jan]

Magnus: I think he is referring to the unwanted new behavior caused by "fixing" this, for which Bug 718279 has been created. And since that is extremely annoying and it should be trivial for someone with a development environment set up to add at least a hidden pref to revert back to the old behavior, would someone please mind having a look at that bug and possibly fix it?