99997 - [SM] "Copy email address" doesn't copy name

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Henrik Gemal]

If you right click on a email adresse like in the header this and select copy 
eamil adress:
Henrik Gemal <[e-mail]>
only [e-mail] gets copied.

Couldn't we copy the entire text?

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

Well, the Name isn't part of the email address, so "Copy email adress"  should
not copy the Name, imho

Comment 2

[SineSwiper]

I disargee.  The name is a part of the e-mail address, according to RFC822, so I
think it should copy that part, too.  I use this to copy addresses and put them
in a To/Cc field in a message, and it would kinda insulting just addressing him
by his e-mail address.

This bug occurs on all OSes, including X/Linux and Windows.

Comment 3

[R.K.Aa.]

*** Bug 146946 has been marked as a duplicate of this bug. ***

Comment 4

[SineSwiper]

Any updates on this bug?

Comment 5

[Bernard Alleysson]

*** Bug 171226 has been marked as a duplicate of this bug. ***

Comment 6

[Klaus Malorny]

This bug applies to the "Compose Mail To" menu item in the same menu, too.

Comment 7

[Jay Smith]

Speakingas a business user in customer service, it is extremely important to for
an address to include a name.  It also makes email management (i.e. filing in
proper folders, etc.) easier because many/most email addresses give you no clue
as to who it is from/to.

You don't like mail addressed to only your street address.  You don't identify
youself only by your phone number.  Why not allow the name to be with the address?

Also note that the Sender (and Recipient in the Sent folder) columns WILL use
the name portion instead of the address portion, if the name portion is present.

Again, as a business user, this is a very important feature.

Failing that, at least let us highlight and copy the email address in that pane
-- on my Mozilla 1.2 running on Red Hat Linux 8, I can't even highlight it. 

Jay

Comment 8

[R.K.Aa.]

*** Bug 193630 has been marked as a duplicate of this bug. ***

Comment 9

[Jon Roland]

The user should be offered the option of copying (or composing mail to) either
the complete address including the display name, or only the email address
without the display name.

Comment 10

[SineSwiper]

Any status on this bug?

Comment 11

[Jay Smith]

The status is that it continues to make my work overly difficult and annoys the
heck out of me. In order to get a full email address with the person's name, I
have to do a Reply or Edit As New or something and then copy the full address
from there into the Compose window. I sometimes have to do these extra steps 20
times a day. What a pain. 

Jay

Comment 12

[David Balažic]

This is still the same in v1.4/w2k.

I recommend changing the "Severity" field to "Normal" as this is a loss of
function, not some extra new feature.

Copying parts of messages is a basic feature of MUA programs.

Now I have to either type over the name manualy or save the entire message to a
file and copy from there.
Pathetic ...

Comment 13

[Jon Roland]

Any further action on this? It is still a priority for me, as it is a constant
chore.

Comment 14

[Jay Smith]

I just upgraded to 1.6 (on Linux; had to compile for RH8). I was amazed to
discover that this lack-of-feature has not yet been fixed.  It is a daily hassle.

Comment 15

[Gervase Markham [:gerv]]

The reason it's still this way is a lot of people like it the way it is. :-) I
fancy that if you changed the behaviour, they would all file bugs complaining
about the "regression". 

If you want the other behaviour, an XPI extension might be the right route to go.

Gerv

Comment 16

[Jon Roland]

I would like both, but 98% of the time I would select the option of
"name+address" over the option of just "address". How about just adding the option?

Comment 17

[Jay Smith]

I thought that it had already been settled that the spec calls for *both* name
and address, per comment #2.

Power users in a business setting really need *names*.  

The problem has to do with 1) personalization adds value to the message and 2)
the gobbledegook email addresses that many people use and the need to be able to
*quickly* file messages (i.e. from the Sent folder into individual client
folders) without having to figure out who the heck [e-mail] is.

If there is a loud group that does not want names, then go with comment #16 and
have *both*.

Jay

Comment 18

[Gervase Markham [:gerv]]

> I thought that it had already been settled that the spec calls for *both* name
> and address, per comment #2.

Don't be silly :-) This is not a question of RFC compliance - the browser can do
whatever it wants here.

Both would be menu bloat - there's no point in having three menu items which do
roughly the same thing (copy link location, copy email address, and copy email
address and name.)

Just because the things you want to do call for email address + name doesn't
mean the things other people want to do call for the same. As I said, an XPI
extension is the way to go here.

Gerv

Comment 19

[Klaus Malorny]

> Both would be menu bloat - there's no point in having three menu items which do
> roughly the same thing (copy link location, copy email address, and copy email
> address and name.)

Do we speek from the same menu? It is about the header menu in message view
pane. I currently get four menu items (build 2003122816):

* Add to Address Book...
* Compose Mail To
* Copy Email Address
* Create Filter from Message...

A fifth menu item wouldn't hurt. Another solution would be that the address is
split into two links. If one clicks on the name part, the name part is copied,
too. If one clicks on the address part, only the address gets copied.

Klaus

Comment 20

[Jay Smith]

a) Since when is compliance "silly".

b) I had not thought about the main menu because I use the context (right click)
menu for this.  But whatever is on one should be on both in this regard.

c) IMHO the only necessary function is copy "name + email address".  IMHO it is
the copy "only email address" which is optional and causing what has been called
menu bloat.

Jay

Comment 21

[timeless]

would you guys *please* cut it out?

1. we don't need a new menu item to do this.
2. we can do this without regressing people who paste into plaintext 
areas. 
the solution is fairly simple. copy email address needs to add 
additional flavors to the clipboard. personally I'd suggest that the 
extra flavors be html and vcard.

pasting into mail compose's addressing widget should check for a 
vcard flavor before it uses the plaintext flavor. If there's a vcard 
flavor it should try to format it as: |"Real Name" <user@host>|.

pasting into plaintext mail compose's message area would paste the 
plaintext format |user@host|.

pasting into html mail compose's message area would paste the html 
format (which would probably look like |<a 
href="mailto:user@host">Real Name</a>|).

pasting into bugzilla's textareas would paste the plaintext format 
which would still be |user@host|.

for bonus points, someone can add support for pasting into an 
addressbook (the book, not a card, not a list) which would grab the 
vcard flavor and make a new address card from it.

Comment 22

[SineSwiper]

My problem is not with trying to paste into the body of the message, but copying
an e-mail address to the To/CC field.  This was originally trying to work around
bug 118905, but then I get blasted by this bug.  Because the e-mail in the
message cannot be copied by dragging with the mouse (no way to select), the only
choice I have is to right-click, and hit "Copy E-mail address".

One would get the expectation that because the entire e-mail address (including
the name) is part of the link, that the function would copy the entire e-mail
address (including the name).  This is not the case.  So, when I paste the
e-mail into the To/CC field, I only get the destination e-mail address and not
the actual person it is attached to.

The only other workaround I can think of is to hit Ctrl+U and copy the e-mail
address there, but that's just plain clunky, and it's essentially getting around
functionality problems between two e-mail bugs (this one and bug 118905). 
Removing the name from an e-mail address is easy and takes all but two seconds.
 Adding the name from an e-mail address is not.  So, given the two choices of
whether to include the name or not, I'd pick the former.

Timeless, the ideas are good, but I see two problems:

1. This would be a Windows only thing.  I don't believe Linux (or many other
OSs) have a destination-dependant clipboard.

2. The format for Mozilla's e-mail areas should be |"Real Name" <user@host>|,
because of the reasons stated above.

Comment 23

[Dave Miller [:justdave]]

For the record, Mac has a multi-typed clipboard.  You can put as many types as
you want on the clipboard for the same object, and the destination app will pick
whichever type it likes best when you paste.

I dunno about Linux, but I'd be surprised if it didn't these days.

Comment 24

[timeless]

linux does too. believe me i know this stuff.

which 'email areas' do you mean?

if you mean addressing, that's covered by this:
> pasting into mail compose's addressing widget should check for a 
> vcard flavor before it uses the plaintext flavor. If there's a vcard 
> flavor it should try to format it as: |"Real Name" <user@host>|.

if you mean the message composition area, well, i'm sorry, but for the time 
being you lose to the people who want the existing behavior. once this is 
supported you can either hack your impl or ask people to switch the default 
impl.

as for how clipboards work, they aren't destination dependent. the thing adding 
to the clipboard adds however many flavors it likes. the thing pasting from the 
clipboard chooses the format it wants.

Comment 25

[Jay Smith]

As for losing to people who want existing behavior, please note that the
"missing" name became "missing" with Mozilla.  Netscape before it *did* include
the name.  This function became "broken" with Mozilla.

So.... I am one of those people who wants the previously-existing behavior which
was (as far as I know) accidentally broken.

Jay

Comment 26

[SineSwiper]

> which 'email areas' do you mean?
> 
> if you mean addressing, that's covered by this:
> > pasting into mail compose's addressing widget should check for a 
> > vcard flavor before it uses the plaintext flavor. If there's a vcard 
> > flavor it should try to format it as: |"Real Name" <user@host>|.

Ahhh...yes, that would work.  Okay, have we finally agreed on an implementation?

Comment 27

[Bob Lockie]

The problem still exists. :-(
Mozilla 1.7b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040222


It is very easy for people to delete the name if they only want the email
address but it is very difficult to copy the name from a link.
All e-mail programs I have seen use the standard RFC format of "name" <address>.
I don't see a problem of doing it this way.

Comment 28

[Bob Lockie]

Interesting.
<a href='mailto:&quot;Bob Lockie&quot; &lt;[e-mail]&gt;'>Blah</a>
The rmb click 'Copy Email Address' puts '"Bob Lockie" <[e-mail]>' in the
clipboard.
'Blah' may not be a person's name BUT RFC822 says an email address may specify a
comment (not necessarily a name) in quotes.

People probably should complain to website owners about mailtos that do not
specify the name but only an email address.

Can people with access to different browsers and email programs other than
Mozilla please confirm that the following syntax works?
<a href='mailto:&quot;Bob Lockie&quot; &lt;[e-mail]&gt;'>Blah</a>

It would be easy enough for mozilla to prepend whatever the text is as a comment
which is what a lot of people want so maybe that should be made clear in the bug
description.

Comment 29

[Peter Lairo]

The plaintext-vs-vcard method does not solve the main problem of being able to copy-paste name+email into a new message (or *anywhere* the user wants).

The best solution IMO is to always copy name+email. It is much easier to later delete the name (or e-mail!) than (as it is currently) to go through several non-discoverable steps to get both.

Workaround (hack!):
1. CTRL+E (edit as new)
2. select & copy name+email
3. close unneeded compose window
4. paste name+email wherever

BTW: This bug also exists in Thunderbird. Shouldn't the Product be "Core" and the Component be "Mailnews: Composition"?

Comment 30

[M]

This has always been bugging me a lot, and I would suggest a very simple solution:

Allow header fields to be selected and copied (as text).

It solves the inability to copy several address at once (eg in Cc:), and the name+address problem. And it would neither add a new menu item nor require an additional clipboard format.

Plain old copy/paste of text works great for everyone. Just enable it.

I suggest marking this bug a duplicate of bug 325232 or bug 167010 (which seems to have a suggested patch attached) or bug 327621. (See also bug 269094)

My current workaround is Ctrl-U (view source), but then I have to hunt through all the mail headers to find what I just had under my mouse before. And I know many users to whom I cannot suggest "view source" because it is too complex/frightening.

Comment 31

[Gervase Markham [:gerv]]

(In reply to comment #30)
> Allow header fields to be selected and copied (as text).

Absolutely. Now that the Subject line is copyable, I've lost count of the number of times I've tried to do this. It might not be as easy, because it's a hyperlink, not just text. But there might be some way to do it.

Gerv

Comment 32

[Max Waterman]

I notice a few comments suggesting that some people want the existing behaviour (copying just the email address), yet I see no proof of this beyond the comments here.

I wonder if there's such a thing as a poll on the mozilla forums where you can ask people what behaviour they would prefer...

Comment 33

[Jay Smith]

I commented on this (wanting email address AND name) in 2003.

I still want that.

However, I now regularly ALSO have use for email address only and I do not wish to lose that functionality.  (My biggest use is getting the email address to paste into PayPal's payment form and that must be actual address only.)

So, I want both, please.

Jay

Comment 34

[Thomas D. (:thomas8)]

It's obvious both copying /plain email address/ and copying /name+email address/ will be useful/required for different scenarios and/or different users.

Fwiw, here's an UI proposal which avoids bloating default menus while providing intuitive in-place access to the alternatives:

Have a look at Firefox Print button from Firefox Button.
It's a dual menu button. Clicking the main part of the button does the default action (Print), while hovering the main button will show a "dropdown"-submenu for easy access to alternative related commands (Print, Print Preview, Page Setup). Perhaps we could try something similar here, using the same UI elements:

|                        +----------------------------+
|Copy Email Address  | > |Pete Smith <[e-mail]> |
|                        |[e-mail]              |
                         +----------------------------+

- Click on Copy Email Address (main button part) will do the default behaviour (for which we should probably have at least a hidden pref)
- Click on "Pete Smith <[e-mail]>" will copy name+email address
- Click on "[e-mail]" will copy plain email address

With this minimally intrusive change, I'd think we can make everybody happy, or at least a lot happier than before. We could even allow the user to toggle the default behaviour in-place:

|                        +----------------------------+
|Copy Email Address  | > |Pete Smith <[e-mail]> |
|                        |[e-mail]              |+---------------+ 
                         |Set default for copying    >||  Name <email> |
                         +----------------------------+|o <email>      |
                                                       +---------------+

Furthermore, we might want to examine how this interacts with settings for (not) using display names from address book, but for the time being, we can just offer to copy whatever is actually shown.

Feedback/comments welcome.

Comment 35

[Jay Smith]

Thomas D.'s proposal sounds good to me.

However, please be sure that both options are available on the right-click menu when the user clicks on an email address.   (That is the only place I knew that this copying was possible anyway.)

Comment 36

[Jay Smith]

Thomas D ....

I still don't see any recognition that the dual behavior is also needed when the user right clicks on an email address.

Please address whether you believe that this dual behavior should be added as well to the right click menu.

Thank you.

Comment 37

[Thomas D. (:thomas8)]

(In reply to Jay Smith from comment #36)
Jay, thanks for feedback. I'm not sure I understand your question.
Yes, my proposal and this bug are both about improving the context menu of recipients on the message header of received messages, in the message reader.
This bug and my proposal are *not* about the context menu of mailto: links within the message body. Otherwise, I am not aware of any other UI part where this proposal could apply. Albeit we should probably duplicate this command in the main Edit menu instead of Copy when focus is on a recipient.

Comment 38

[Jay Smith]

(In reply to Thomas D from comment #37)

Thomas,

And I am not sure exactly what you were saying in comment #37 -- there seems to be one or more words missing.  

In comment #34, if I am reading correctly, you seem only to be addressing changing the behavior of a menu-bar button.  That's fine as far as that goes.

You also specifically state in comment #37: "This bug and my proposal are *not* about the context menu of mailto: links within the message BODY."  [The all caps are mine.]

However...

a) I have not been meaning to refer to the BODY, I have been referring to the email address links in the message HEADER.  I am sorry if I was previously imprecise.  However, what gets improved for the email links in the header should also apply to such links to the body.  The current right-click behavior is almost identical for both.

b) The original bug description is about the email address links in the message HEADER region and specifically the lack of feature when you *right click* such an email address in the message HEADER.

c) Your proposal is great, as far as it goes.  However it deals with a much less common case.  It is my understanding (please correct me if I am wrong) that default (and probably 99%) of user installations/configurations do not currently have a "Copy Email Address" button in the main menu bar.  Sure such a button can probably be added by the user (I do not know how, offhand) -- and it could be improved by having the behavior you propose.

d) But, it is my understanding that 100% of default installations/configurations have a default right-click behavior when you click on an email address in a message HEADER or message BODY.  My point is that it would be much more valuable to *also* add the "copy name+email address" to that right-click context menu.

Thanks.

Comment 39

[Thomas D. (:thomas8)]

(In reply to Jay Smith from comment #38)

Fortunately, I fully agree with Jay on everything he says in comment 38 (a,b,d), except for the misunderstanding of my proposal in c). I never meant to suggest a button, I only wanted to use the dual print menu from FF main application button as an illustration of the proposed dual menu (split menu) for the context menu of mail recipients. I realize I might have been talking too much about buttons and not clearly enough about context menus in my comment 34, sorry for the confusion.
Technically, that dual menu might be a dual button, but I didn't check that and I think the FF print button is a bit of a hack iirc.

Comment 40

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #39)
> (In reply to Jay Smith from comment #38)
> Technically, that dual menu might be a dual button, but I didn't check that
> and I think the FF print button is a bit of a hack iirc.

Sorry, I've done it again. I'm not talking about a print button on a toolbar, I am talking about the Print-dual-menu-"button"-*menu* which is part of the FF main button *menu*. Sorry, I don't have time to look them up in FF source code and XUL reference.

Comment 41

[Thomas D. (:thomas8)]

(In reply to Jay Smith from comment #38)
> a) what gets improved for the email links in
> the header should also apply to such links to the body.  The current
> right-click behavior is almost identical for both.

The mailto: links in the body might appear "almost identical", but they are a  different scenario (vs. contacts in the header pane), and I doubt we can easily transfer the UI proposed in my comment 34 to (mailto) links in the body (would need a new bug, not this one). Compare:

*Recipient links in message reader header pane:*
_Display Name_ = "Display Name"  + <mail address>

On the header, we know for sure that this link and the link text are a clearly delimited logical unit of "Display Name" + <mail address>, even if the link text might be just a repetition of the mail address, or less useful display name like _Administration_.

*Mailto links in body:*

E.g., two typical examples of mailto links in body of html mails:
a) Pete Smith <[e-mail]_> = "Pete Smith" + "[e-mail]" + <[e-mail]>
b) Please _contact us_ = "contact us" + <[e-mail]>

Logically, both examples are:
"Any pre-link text" + "Any link text" + <mail address>

In example of a) we have no way of veryfying that and how much of the pre-link text logically forms part of the link. The "display name" in front of the mailto link could be one word, two words, or three words, or none (unrelated words).

In example of b) again we have no way of veryfying that the freely definable link text is actually a name or appropriate description for which it makes sense to copy that. I agree there should be a way of copying any link text, but that surely needs a different bug, probably in the Core product.

Comment 42

[Thomas D. (:thomas8)]

Any objections against moving this bug into the "MailNews Core" product, "Address book" component, so that it applies to both Thunderbird and SeaMonkey (as hinted in Peter's comment 29)?
Or is it better to file a new bug against Thunderbird:Message Reader UI?

Comment 43

[Philip Chee]

The Addressbook has separate implementations in Thunderbird and in SeaMonkey. There is some shared code in MailNews Core, but this is all front end stuff, so you'll need separate bugs for SeaMonkey and for Thunderbird.

Comment 44

[Thomas D. (:thomas8)]

For Thunderbird, this is Bug 232021.

Comment 45

[Ulf Zibis]

(In reply to Thomas D. from comment #34)
> With this minimally intrusive change, I'd think we can make everybody happy,
> or at least a lot happier than before. We could even allow the user to
> toggle the default behaviour in-place:

Please compare to solution, given by ThunderPlunger Add-on.

Comment 46

[Thomas D. (:thomas8)]

Ulf, can you pls file a screenshot of the respective feature of ThunderPlunger Addon?

Comment 47

[Ulf Zibis]

Attachment: Screeshot - Copy email with name

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #46)
> Ulf, can you pls file a screenshot of the respective feature of ThunderPlunger Addon?

Yes, pleasantly.
The ThunderPlunger feature is only possible on the From: field, but unfortunately not on To:, CC: and BCC: fields.

Comment 48

[Frank-Rainer Grahl (:frg)]

Attachment: 99997-copyemailaddress.patch

Simple port of Bug 232021. Can't be taken to 2.49 because of l10n changes.

The copy newsgroup functionality in TB would need to be ported in a follow-up bug in desired.

Comment 49

[Frank-Rainer Grahl (:frg)]

> in desired

if desired :)

Comment 50

[Frank-Rainer Grahl (:frg)]

en-US only test build can be found here:

http://www.wg9s.com/comm-253/

Comment 51

[Ian Neal]

Comment on attachment 9033410 [details] [diff] [review]
99997-copyemailaddress.patch

>+++ b/suite/locales/en-US/chrome/mailnews/msgHdrViewPopup.dtd
> <!ENTITY CopyEmailAddress.label            "Copy Email Address">
> <!ENTITY CopyEmailAddress.accesskey        "C">
>+<!ENTITY CopyNameAndEmailAddress.label "Copy Name and Email Address">
Nit: extra spaces required to line it up with line above
>+<!ENTITY CopyNameAndEmailAddress.accesskey "N">
> <!ENTITY CreateFilterFrom.label            "Create Filter Fromâ¦">
> <!ENTITY CreateFilterFrom.accesskey        "F">
r/a=me

Comment 52

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/aad2453b9a23
Copy email and address from header to clipboard. r=IanN

Comment 53

[Frank-Rainer Grahl (:frg)]

https://hg.mozilla.org/releases/comm-esr60/rev/fa9cd87e13eeb8fd26f3e393073d354b8ff3e1b0