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.

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.

fixed on the trunk. There are still some additional changes I want to play around with going forward.....

I ported this to the 0.6 branch too.

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...

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.

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!

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

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 ?

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.

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.

Comment on attachment 265973 [details] [diff] [review] Fix for remaining issues [Checkin: Comment 49] Make sense, r=philringnalda

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.

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. }}

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. }}

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 }}