Closed Bug 99997 Opened 19 years ago Closed 11 months ago
[SM] "Copy email address" doesn't copy name
If you right click on a email adresse like in the header this and select copy eamil adress: Henrik Gemal <firstname.lastname@example.org> only email@example.com gets copied. Couldn't we copy the entire text?
Well, the Name isn't part of the email address, so "Copy email adress" should not copy the Name, imho
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.
*** Bug 146946 has been marked as a duplicate of this bug. ***
Any updates on this bug?
*** Bug 171226 has been marked as a duplicate of this bug. ***
This bug applies to the "Compose Mail To" menu item in the same menu, too.
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
*** Bug 193630 has been marked as a duplicate of this bug. ***
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.
Any status on this bug?
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
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 ...
Any further action on this? It is still a priority for me, as it is a constant chore.
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.
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
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?
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 firstname.lastname@example.org is. If there is a loud group that does not want names, then go with comment #16 and have *both*. Jay
> 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
> 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
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
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.
Assignee: sspitzer → neil.parkwaycc.co.uk
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.
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.
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.
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
> 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?
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.
Interesting. <a href='mailto:"Bob Lockie" <email@example.com>'>Blah</a> The rmb click 'Copy Email Address' puts '"Bob Lockie" <firstname.lastname@example.org>' 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:"Bob Lockie" <email@example.com>'>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.
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"?
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.
(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
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...
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
Assignee: neil → nobody
QA Contact: laurel → message-display
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 <firstname.lastname@example.org> | | |email@example.com | +----------------------------+ - 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 <firstname.lastname@example.org>" will copy name+email address - Click on "email@example.com" 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 <firstname.lastname@example.org> | | |email@example.com |+---------------+ |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.
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.)
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.
(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.
(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.
(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.
(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.
(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 <firstname.lastname@example.org_> = "Pete Smith" + "email@example.com" + <firstname.lastname@example.org> b) Please _contact us_ = "contact us" + <email@example.com> 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.
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?
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.
Summary: "Copy email address" doesn't copy name → [SM] "Copy email address" doesn't copy name
(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.
Ulf, can you pls file a screenshot of the respective feature of ThunderPlunger Addon?
(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.
Attachment #8693627 - Attachment description: ThunderPlunger - Copy email with name.png → Screeshot - Copy email with name
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.
> in desired if desired :)
en-US only test build can be found here: http://www.wg9s.com/comm-253/
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
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/comm-central/rev/aad2453b9a23 Copy email and address from header to clipboard. r=IanN
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.