Closed Bug 240138 Opened 16 years ago Closed 12 years ago

Show just the name and not the email address in the message pane

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird0.6

People

(Reporter: mscott, Assigned: mscott)

References

Details

Attachments

(5 files, 1 obsolete file)

If the email address is in one of your address books, we should just show the
user's name instead of the full name + email address in the message pane.

Outlook and mail.app both do this and it's a great way to reduce space in the
message pane for known addresses. And it lets folks know if the message is from
someone in one of their ABs.
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird0.7
alec might be interested in this feature as well given a conversation he and I
recently had.
Comment on attachment 145854 [details] [diff] [review]
the fix
[Checkin: Comment 4 & 6]

David, can you check my address book database logic to make sure i'm not doing
anything harmful / wrong?

I also delay opening the address book up to do this until after you click on
the first message in the message pane. So we shouldn't impact startup
performance.
Attachment #145854 - Flags: superreview?(bienvenu)
fixed on the trunk. There are still some additional changes I want to play
around with going forward.....
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Blocks: 240476
I ported this to the 0.6 branch too.
Target Milestone: Thunderbird0.7 → Thunderbird0.6
Was there any thought of making this configurable? I have acres of horizontal
space in my message pane, and I've now lost useful information as to which of
the many email addresses the sender had used. OK, I can reveal it by clicking,
but previously it was visible...

you can't please everybody :)
This is pretty bad UI.  I'd like to see at least a config option for this, as I
don't need to know who's in my address book or not, I need to know their email
address.  Reopening so we can have some discussion on this...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I have different email addresses with the same name. When I get new mail I want
to see to which address it was delivered. I hate the displaying of the name
only. I totally agree with comment 8. We should add a pref for this so people
whose won't have this feature can disable it.
Target Milestone: Thunderbird0.6 → Thunderbird0.5
Target Milestone: Thunderbird0.5 → Thunderbird0.6
FYI this is the behavior used by Outlook (which does it for all addresses not
just people you know) and mail.app.

Having used outlook at work, and hearing the number of people complain about
hiding email addresses, I don't think this is a valid arguement.  Outlook and
Mail.app don't do everything right, and I strongly believe this is one of the
things they are not correct on.
(In reply to comment #11)
> Having used outlook at work, and hearing the number of people complain about
> hiding email addresses, I don't think this is a valid arguement.  Outlook and
> Mail.app don't do everything right, and I strongly believe this is one of the
> things they are not correct on.

Right, we shouldn't immitate any other mail.app and Scott please don't use
Outlook as reference for implementing such features. That's not a good start for
a discussion. Meanwhile I got negative feedback from a lot of people when asking
them about that feature! 
Well, how about a pref option (perhaps hidden for now, but a UI if enough votes
for it)?  Looking at the patch it shouldn't be a big deal to add.  
This "feature" (again) is *not* helpful.
Often, you get mails with forged names. Until now, you could at least have a
quick look at the *address*...

Actually, I consider this "feature" a security hazard.

Scott, it would be *very* helpful if you'd just *propose* features without
checking them in immediately, so that they can be *considered*. :(
This feature is not helpful. I got three people with the exact same name in my
address book - even if I had not it'd be helpful if the choice how much space on
my message pane I want "wasted" was mine. What about people who happen to have
one address@home and one@work? I'd like to be able to tell the difference with
just one look.

Reducing information to not confuse the new user is not always a good idea,
especially if this means that it takes the experienced user time to get the
information he wants. Experienced users tend to have less time than new ones.
add pref UI under advanced / General Settings where the other seamonkey
compatibility UI prefs are going for allowing a user to turn this feature off.

We reload the message pane when the pref is toggled to show live changes.

The verbage of the pref is subject to change.
Thanks Scott.  
How about changing:

+<!ENTITY showCondensedAddresses.label  "Show just the friendly name for people
I know in the message pane.">

to

+<!ENTITY showCondensedAddresses.label  "Show only display name for people in my
address book.">

A bit more discriptive than "people I know".
Does the tooltip text get set on the collapsed-style header?
-  if (displayName && useDisplayNameForAddress(emailAddress))
+  if (gShowCondensedEmailAddresses && displayName &&
useDisplayNameForAddress(emailAddress))
+  {
     addressNode.setAttribute('label', displayName); 
+    addressNode.setAttribute('tooltiptext', emailAddress);
+  }
I disagree. "We" should always show the full identfication of the sender of the
mail. The ID includes the Real Name and the email adress.

If just one is to be shown, I'd vote for the email adress, since this is most
often more unique than the real name and also more interesting.

Also I don't care about what Outlook does. I don't use it. 
Sorry, forgot to add: As Karsten pointed out, this might introduce security
problems. Because of this (and because of the irritation this WILL create), the
default should be that this feature is disabled.

IMO, the feature should be dumped...
What happens with shared LDAP-connected address books? In this case the user
doesn't have control on his address book and esp. with company addr. books it
might lead to confusions, when I additionally have my colleague with his private
address in my personal abook.
Neil I used to try to set the tooltip text on the email address node but for
some reason that only works for the form address, I couldn't get the tooltip to
show up for the other fields and hadn't gotten back around to looking at it again.
(In reply to comment #16)
> Created an attachment (id=146206)
> pref UI to disable this feature
I'd prefer an UI to *enable* this behaviour. Which means that it is disabled by
default.
I was away on vacation - I like this feature in theory but definitely agree it
should be configurable. I'm still undecided if I personally like it in Outlook
or not...
I would vote for removing this or at least deactivate it by default... It isn't
a good idea to try to clone Outlook! Outlook is *not* the best mail software! If
Thunderbird really gets as bad as Outlook then I'll have to look for another
mail client!
Attached patch another possible tweak. (obsolete) — Splinter Review
still playing around with this. This possible tweak always shows the address
for the from field, only compressing the to/cc fields for addresses of people
you already know.
(In reply to comment #29)
> still playing around with this. This possible tweak always shows the address
> for the from field, only compressing the to/cc fields for addresses of people
> you already know. 

And what if I want to know if I've sent a mail to the firm-address of $PERSON or
to the private-address of $PERSON? Why do you want to blow up the
Thunderbird-Sourcecode only to get a less informative Header-Display? Keep it
simple and simply display the mail address!
(In reply to comment #29)
> Created an attachment (id=147198)
> another possible tweak.
> 
> still playing around with this. This possible tweak always shows the address
> for the from field, only compressing the to/cc fields for addresses of people
> you already know. 

Dislike it. In email/news, a "person" is identified by *THE* *COMBINATION* of
Realname + Email. Showing just one is not good enough. Never. Also the "reason"
that Outlook does it, is not a good reason. If it were a reason, it would be to
NOT do it.

Scott - why is it, that you completely ignore the comments that are made here?
It is impossible to discuss with you, which is a tremendously bad sign.
(In reply to comment #30)

> to the private-address of $PERSON? Why do you want to blow up the
> Thunderbird-Sourcecode only to get a less informative Header-Display? Keep it
> simple and simply display the mail address!

Also see Bug 230182...
guys, its hooked up to a preference. chill out.
OTOH, it's hooked up wrong. It should be, that a user has to enable that
feature. Further, I think it's a total error to even re-implement that Outlook bug.

OTOH, it's an issue with Scotts lack of communication. He doesn't react to
anything. He just does something.
Feel free to turn it off. Tools / Options / Advanced if this bothers you. That's
why I added those UI controls.



As I said - it should be disabled by default, for all the reasons posted in this
bug. It might be nice to have that feature, but it really should have to be enabled.
dude, you've made yourself clear. just because you have an opinion doesn't mean
it is right. Let the feature get flushed out before you reiterate yourself for
the Nth time. Stop using nightly builds if you don't want experimental features.
Please.

These are nightlies, they are subject to radical change and experimentation.  We
know your vote.  If your not willing to be subject to this, go with more
finalized releases.
(In reply to comment #37)
> dude, you've made yourself clear. just because you have an opinion doesn't mean
> it is right. Let the feature get flushed out before you reiterate yourself for
> the Nth time. Stop using nightly builds if you don't want experimental features.

Alecf, and just because you've got an oppinion, it doesn't have to be right
either - even if it happens that you seem to agree to Scott. But then, if you
read the comments in this bug, it doesn't look like I'm alone with my opinion,
does it?

Also, when I use nightlies, I don't have to like every change that's made, or is
that now required? Are users of nighlies no longer allowed to dislike bad
changes like this one?

Thinks about it. 

EOD, as far as I'm concerned.
I don't really care about this, but here's my two cents:
1) Maybe AB entries could be styled differently (color, bold). Obviously, this
doesn't give you any more space (and may reduce it).
2) Maybe AB entries could use the AB 'Display' name? It seems that if you have
two AB entries with the same name (or two entries for the same person?), this
would be a good way/place to distinguish them.

In my mind's eye, a color-mixing style is less than aesthetic.

FWIW, I think the 'expanded for From:' and 'collapsed for To: and CC:' is better
than collapsing everthing.

Also FWIW, I changed some names in the AB while tinkering with this stuff and
the changes were not subsequently reflected in the message pane even after
switching messages and restarting. No biggie for me, but maybe less effective
for people who deal with mail archives regularly? (Think maiden vs. married or
whatever.)
Just searched for the pref and found it with Advanced --> General Settings,
which is not very inspiring. How about putting it into Display?
*** Bug 242710 has been marked as a duplicate of this bug. ***
Comment on attachment 145854 [details] [diff] [review]
the fix
[Checkin: Comment 4 & 6]

clearing obsolete request
Attachment #145854 - Flags: superreview?(bienvenu)
Blocks: 309057
Comment on attachment 146325 [details] [diff] [review]
add tooltips to condensed address nodes
[Checkin: Comment 52 (double)]

>Index: msgHdrViewOverlay.js
>===================================================================
>RCS file: /cvsroot/mozilla/mail/base/content/msgHdrViewOverlay.js,v

This was checked in but seems obviously wrong:

>+// Public method called to generate a tooltip over a condensed display name
>+function fillInEmailAddressTooltip(addressNode)
>+{
>+  var emailAddress = addressNode.getTextAttribute('emailAddress');

|emailAddress| is unused.

>+  var tooltipNode = document.getElementById("attachmentListTooltip");
>+  tooltipNode.setAttribute("label", attachmentName);

|attachmentName| is undefined.

>+  return true;
> }

Scott, can you fix this ?
QA Contact: front-end
Scott, do you have special plans with the tooltips?

+    addressNode.setAttribute("tooltiptext", emailAddress);
+    addressNode.setAttribute("tooltip", "emailAddressTooltip");

That doesn't make much sense because tooltip won't be used. If we don't plan to enhance the tooltip for display names with images or somewhat else we should remove emailAddressTooltip completely. I can come up with a patch if you want it.
Scott, I have removed the unnecessary tooltip emailAddressTooltip. We don't need it because we can also reach it by setting tooltiptext. Same applies for the attachmentListTooltip. I also removed that one to get a consistency. I also updated the function AddExtraAddressProcessing which will now remove the tooltip when an address wasn't found inside the address book and the full email address is already shown.
Attachment #265973 - Flags: review?(mscott)
Comment on attachment 265973 [details] [diff] [review]
Fix for remaining issues
[Checkin: Comment 49]

Thanks Henrik. This patch looks good to me, asking Phil for a review too.
Attachment #265973 - Flags: superreview+
Attachment #265973 - Flags: review?(philringnalda)
Attachment #265973 - Flags: review?(mscott)
Comment on attachment 265973 [details] [diff] [review]
Fix for remaining issues
[Checkin: Comment 49]

Make sense, r=philringnalda
Attachment #265973 - Flags: review?(philringnalda) → review+
mail/base/content/msgHdrViewOverlay.xul 1.23
mail/base/content/msgHdrViewOverlay.js 1.90

And after three years, it also make sense to me to close this bug, and file any regressions or desired changes or cleanup as new bugs.
Status: REOPENED → RESOLVED
Closed: 16 years ago12 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Version: unspecified → Trunk
Attachment #145854 - Attachment description: the fix → the fix [Checkin: Comment 4]
Attachment #145854 - Attachment description: the fix [Checkin: Comment 4] → the fix [Checkin: Comment 4 & 6]
Attachment #265973 - Attachment description: Fix for remaining issues → Fix for remaining issues [Checkin: Comment 49]
Comment on attachment 146063 [details] [diff] [review]
additional change to expose the email address in the context menu
[Checkin: Comment 50]

{{
scott%scott-macgregor.org	2004-04-13 17:40	 	Bug #240138 --> now that we don't show the email address in msg headers for people we know, expose
the email address in the context menu as a disabled menu item.
}}
Attachment #146063 - Attachment description: additional change to expose the email address in the context menu → additional change to expose the email address in the context menu [Checkin: Comment 50]
Comment on attachment 146206 [details] [diff] [review]
pref UI to disable this feature
[Checkin: Comment 51 (double)]

Trunk and branch:
{{
scott%scott-macgregor.org	2004-04-15 16:36	 	Follow up to Bug #240138 --> Add pref UI for turning on / off showing just the display name
for contacts you know.
}}
Attachment #146206 - Attachment description: pref UI to disable this feature → pref UI to disable this feature [Checkin: Comment 51 (double)]
Comment on attachment 146325 [details] [diff] [review]
add tooltips to condensed address nodes
[Checkin: Comment 52 (double)]

Trunk:
{{
scott%scott-macgregor.org	2004-04-19 17:21	 	Bug #240138 --> Add tooltips showing the email address on address nodes we are showing just the display name for.
}}

Branch:
{{
scott%scott-macgregor.org	2004-04-19 13:42	 	Bug #240138 --> show tooltips over email addresses where we are hiding the email address
}}
Attachment #146325 - Attachment description: add tooltips to condensed address nodes → add tooltips to condensed address nodes [Checkin: Comment 52 (double)]
Attachment #147198 - Attachment is obsolete: true
OS: Windows 2000 → All
Hardware: PC → All
You need to log in before you can comment on or make changes to this bug.