Closed Bug 289411 Opened 17 years ago Closed 10 years ago

e-mail tag is not visible when thread is collapsed

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 9.0

People

(Reporter: torben.putkonen, Assigned: +)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

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.
seamonkey bug 122908, also bug 185801
confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: front-end
Duplicate of this bug: 354799
Assignee: mscott → nobody
Blocks: tb-tagsmeta
OS: Linux → All
Hardware: x86 → All
Summary: e-mail label is not visible when thread is collapsed → e-mail tag is not visible when thread is collapsed
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.
duping to older bug
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 135472
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
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Blocks: 268066
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.
Attachment #548410 - Flags: review?(bugmail)
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 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.
Attachment #548410 - Flags: review?(bugmail) → ui-review?(bwinton)
(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.)
(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.
(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 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.
Attachment #548410 - Flags: ui-review?(bwinton) → ui-review+
(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.
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?)
(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.
(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 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.  :)
Attachment #548410 - Flags: review?(dbienvenu)
I tweaked the previous patch a little. This is what I'll land. Thx for the patch.
Attachment #548410 - Attachment is obsolete: true
Attachment #556114 - Flags: review+
Attachment #548410 - Flags: review?(dbienvenu)
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.
this is what I landed - http://hg.mozilla.org/comm-central/rev/e8423ae0f0ac
Attachment #556114 - Attachment is obsolete: true
Attachment #556117 - Flags: review+
fix checked in, thx for working on this, Robin.
Status: REOPENED → RESOLVED
Closed: 13 years ago10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 9.0
Assignee: nobody → +
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?
See Bug 718279 for a request to make this configurable. Like RDL said, this totally breaks some use cases of tags.
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...
Maxim: this issue is closed (RESOLEVD FIXED as of thunderbird 9.)
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?
You need to log in before you can comment on or make changes to this bug.