selecting text in full header mode fails

What exactly do you mean by a *text* e-mail address? And why is this bug Windows
only?

pi

Boris, Seth was just using a W2K PC to file the bug.

I guess this would include the ability to select and copy the sender's or
recipient's names too, which can't be done from the message pane header view at
the moment. (not to mention getting a menupopup as punishment for trying)

please read this comment as well

http://bugzilla.mozilla.org/show_bug.cgi?id=61497#c120

I'm hoping I can get some help from neil on this one, as it's right up his alley.

we'd want to make it so the user can select email addresses on left click drag.

but we want to keep the right click ability to get that context menu, which is
per address.

We also want to keep the "linkified" look, where it changes color on mouseover.

for extra credit (beyond the scope of of this bug) would be making it so you can
select multiple headers at once.

My gut tells me that is much harder.

nominating.

note, a very lame work around is to view source (ctrl + u) and do your
select/copy there.

Mail triage team: nsbeta1+/adt3

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

What I want to do, which brought me to this bug, is to copy entire messages,
including the main headers, to a document, to make a record of discussions on a
particular issue. For this I would want to be able to select and copy the
headers and the text in the format in which they appear on the screen.

Copying from the message source (comment 7) is not adequate for several reasons.
One is that I get lots of irrelevant headers which I have to delete. Another is
that the source is in the source encoding which has not been regularised by
Mozilla, e.g. it may be full of =20's or may be raw UTF-8 etc, and the Windows
clipboard does not recognise Content-Type etc headers. Even some sender names
are in a strange format in the source e.g. I have a source sender line in the
form (adjusted to protect privacy):

From: =?iso-8859-1?Q?Karlj=FCrgen_Xxxxxxxxx?= <email address hidden>

which is displayed correctly in the header pane as:

Karljürgen Xxxxxxxxx <email address hidden>

but there seems to be no way to copy that u umlaut to the Windows clipboard.

My suggestion would be that when in a message Select All (Edit - Select - All or
ctrl-A) should select also the headers - whichever ones are displayed.

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

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

(In reply to comment #6)
> we'd want to make it so the user can select email addresses on left click drag.
>
> but we want to keep the right click ability to get that context menu, which is
> per address.
>
> We also want to keep the "linkified" look, where it changes color on mouseover.
>
> for extra credit (beyond the scope of of this bug) would be making it so you can
> select multiple headers at once.
>
> My gut tells me that is much harder.
>
> nominating.

We could add an item such as "Copy Email Address With Name" (or one with a
better wording) to the context menu. The user doesn't have the freedom to drag
and select arbitrarily portions of the name, but this "Copy Email Address With
Name" would be good enough for most cases and not that hard to implement.

The exact semantics would be to copy the MIME-decoded content (exactly as
displayed in the header pane) of the item chosen by the user, to solve the
problem addressed in comment #10, e.g. to copy "Karljürgen Xxxxxxxxx
<email address hidden>", not "=?iso-8859-1?Q?Karlj=FCrgen_Xxxxxxxxx?=
<email address hidden>" to the clipboard.

"Copy Email Address With Name" is not sufficient for one very useful purpose;
the ability to copy *all* the recipients of a particular message to compose a
new message, but not in reply to the one you are copying from.

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

Re comment #13
Quote from bug #302913, marked as duplicate:
The message headers can't be copied in memory for paste (header title can't be
selected, and only one row max).

Expected results:
Copy-paste message header in one operation, which would look like this when pasted:
Subject: asdf
From: ...
Date: ...
To: ...
(or all message headers if selected).

I have some idea on solving this bug.

Its possible to add one more item on the popup menu(when you left click on the
from field) called copy header, and we can paste the whole header field
wherever we want.

alternatively, the item may also called view the header in plain text, in this
case, the whole mail header will display in a popup window in plain text, the
user may select the part they want to copy and paste somewhere else.

I'm not sure if anyone agree with my idea, if so, i can post the patch in one day.

(In reply to comment #14)
> "Copy Email Address With Name" is not sufficient for one very useful purpose;
> the ability to copy *all* the recipients of a particular message to compose a
> new message, but not in reply to the one you are copying from.

We can add another menu item for copying all the recipients. :)
Another idea that comes to my mind is a menu item that pops up a window with all
the recipients, each with a checkbox (checked by default), to let the user
choose exactly which recipients wanted.

I think we can also replace "Copy Email Address" with, say, "Copy Email Address
with Name" and name it just "Copy", for it is obvious what to be copied, and
name the new feature "Copy Multiple".

This is all very complicated. Why not (In reply to comment #18)
> (In reply to comment #14)
> > "Copy Email Address With Name" is not sufficient for one very useful
purpose;
> > the ability to copy *all* the recipients of a particular message to compose
a
> > new message, but not in reply to the one you are copying from.
>
> We can add another menu item for copying all the recipients. :)
> Another idea that comes to my mind is a menu item that pops up a window with
all
> the recipients, each with a checkbox (checked by default), to let the user
> choose exactly which recipients wanted.
>
> I think we can also replace "Copy Email Address" with, say, "Copy Email
Address
> with Name" and name it just "Copy", for it is obvious what to be copied, and
> name the new feature "Copy Multiple".

This is all very complicated. Why not simply allow the user to highlight the
names and addresses like text? They can still click or right click on them!

I think why we don't simply let the user highlight the part they intersted is
because the message header part of mozilla mail is combine with few components
(label and textbox etc) rather than one (like Evolution does), thus, its hard to
implement the function you mentioned. Otherwise, this topic will not last for
about 5 years( since bug 61497) and with no solution...

Created attachment 199906
THis patch is what I mentioned in comment 17

This patch simply add one more feature and doesn't influent any other part of
codes.

Created attachment 200039
Revised from last patch

-> enh to take it off the "bug" radar.

4xp means it worked in Netscape 4 and therefore is broken by not working in Mozilla and not an enhancement

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

Is the patch from comment #22 still waiting for review?

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

This bug might be a good idea for improved UI

UI Refresh has become one of the goals to improve Thunderbird Adoption as desired by David A. From a decent UI, I expect that I can copy everything that looks like text, especially like in this case, where copying the headers (adresses etc.) could be higly beneficial in everyday scenarios like composing a new mail to a number of recipients from another mail without replying to that other mail.

On implementation, please allow mouse drag to highlight, highlighting across different headers (e.g. from AND cc) and keyboard highlighting using Shift.

Since new message reader plans are to return to Netscapes' scroll-the-whole message format, this might be the right time to fix this usability "regression" from Netscape 4? Also consider that even MS Outlook Express has had this feature ever since...

Therefore: Will the final version of message reader finally offer the possibility of selecting across several adresses (via dragging over or shift+cursor keys) so as to allow copying them into a new email etc?

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

Ubuntu Bug:
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1085

This is still extant in Thunderbird 2.0.0.23.

My particular use case is:

I have received an email from someone in Korea, with a Korean name. He doesn't have a signature. The only place I can get at his name is in the From: header. I can't type Korean, so I can't copy it manually; I can't copy his name from the message source, because it hasn't been MIME decoded; and I can't select the text from the From: header because Thunderbird doesn't support it.

So I am, basically, stuffed. I'm going to have to refer to him to my boss as 'That guy from Korea'.

This bug makes Thunderbird extremely frustrating when trying to put together mails to
multiple addresses quickly.

You can’t copy and paste email addresses from To, From fields, etc, drag and drop them into other emails, and so on-- way too clunky and difficult to manage!

I agree. I have the same problem as David in Comment 32, though I have discovered a workaround that choosing Reply or Forward on the original message then lets me copy the name from the To: field or the body text, respectively.

What's even more annoying is when I want to copy a list of 50 e-mail addresses (because they haven't adopted a litserv yet) and paste them as recipients of an e-mail I've composed in another window. The only way around this is to do Reply All, accept that most of the recipients will be CC instead of the somewhat-arbitrarily chosen To: (selected based on who sent the message I Reply All on), and then replace the subject, body, options, From, etc. with the new content.

 (In reply to comment #20)
> I think why we don't simply let the user highlight the part they intersted is
> because the message header part of mozilla mail is combine with few components
> (label and textbox etc) rather than one (like Evolution does), thus, its hard to
> implement the function you mentioned. Otherwise, this topic will not last for
> about 5 years( since bug 61497) and with no solution...

No, this topic won't last for 5 years with no solution...we're already beyond 10.

Gary, can you check how badly is patch bitrotted? (Patch author's email is dead)

I suppose there must be a lot of reports on this on getsatisfaction, but I don't have time to research. If you find some, please tag them "bug 167010" so that URL of this bug will expose them. Then, we need to label one of these reports canonical.

While this bug may not technically depend on Bug 136897, and may differ in other ways, they are related in that they address a similar type of problem in a similar part of the UI. Unfortunately bmo doesn't have many ways yet of expressing such relations. Let's keep a link then, in see also.

I guess we might want to keep Thunderbird bug 327621 which requests the same so that it can be more easily found and remembered for the *Thunderbird* Product. Technically, it's a dupe of this bug 167010.

There are actually two extensions that provide this functionality in different ways:

AddressContext
https://addons.mozilla.org/en-us/thunderbird/addon/addresscontext/

RecipientBox
https://addons.mozilla.org/en-US/thunderbird/addon/recipientbox/

Unfortunately, they are both so outdated that AddressContext only works for versions up to TB2 (although a user comments that (s)he was able to get it to function for TB5 with a workaround), and RecipientBox has been "disabled by an administrator" while only working for up to TB3.

In order to be able to use at least one of these great and very useful extensions, I am still using TB3.

Will someone please incorporate this functionality into Thunderbird?

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

Comment on attachment 200039
Revised from last patch

>? patch.txt
>Index: resources/content/messageWindow.xul
>===================================================================
>RCS file: /cvsroot/mozilla/mailnews/base/resources/content/messageWindow.xul,v
>retrieving revision 1.81.2.1
>diff -u -w -r1.81.2.1 messageWindow.xul
>--- resources/content/messageWindow.xul 22 Sep 2005 13:38:25 -0000 1.81.2.1
>+++ resources/content/messageWindow.xul 19 Oct 2005 03:46:40 -0000
>@@ -126,6 +126,9 @@
> <menuitem label="&CreateFilter.label;"
> accesskey="&CreateFilter.accesskey;"
> command="cmd_createFilterFromPopup"/>
>+ <menuitem label="&CopyMailHeader.label;"
>+ accesskey="&CopyMailHeader.accesskey;"
>+ oncommand = "CopyMailHeader()"/>
> </popup>
>
> <popup id="allHeadersPopup" onpopupshowing="return fillAllHeadersPopup(document.popupNode);" popupanchor="bottomleft">
>Index: resources/content/messenger.xul
>===================================================================
>RCS file: /cvsroot/mozilla/mailnews/base/resources/content/messenger.xul,v
>retrieving revision 1.258.2.1
>diff -u -w -r1.258.2.1 messenger.xul
>--- resources/content/messenger.xul 22 Sep 2005 13:38:25 -0000 1.258.2.1
>+++ resources/content/messenger.xul 19 Oct 2005 03:47:09 -0000
>@@ -143,6 +143,10 @@
> <menuitem label="&CreateFilter.label;"
> accesskey="&CreateFilter.accesskey;"
> command="cmd_createFilterFromPopup"/>
>+ <menuitem label="&CopyMailHeader.label;"
>+ accesskey="&CopyMailHeader.accesskey;"
>+ oncommand = "CopyMailHeader()"/>
>+
> </popup>
>
> <popup id="allHeadersPopup" onpopupshowing="return fillAllHeadersPopup(document.popupNode);" popupanchor="bottomleft">
>Index: resources/content/msgHdrViewOverlay.js
>===================================================================
>RCS file: /cvsroot/mozilla/mailnews/base/resources/content/msgHdrViewOverlay.js,v
>retrieving revision 1.141.2.1
>diff -u -w -r1.141.2.1 msgHdrViewOverlay.js
>--- resources/content/msgHdrViewOverlay.js 19 Sep 2005 23:26:28 -0000 1.141.2.1
>+++ resources/content/msgHdrViewOverlay.js 19 Oct 2005 03:47:29 -0000
>@@ -916,6 +916,26 @@
> }
> }
>
>+// CopyMailHeader copy the major part of mailheader, it enable user to paste the header to other files as they needed
>+
>+function CopyMailHeader()
>+{
>+ var header="";
>+ for(headername in currentHeaderData)
>+ {
>+ if(headername in gExpandedHeaderView )
>+ {
>+ var headerfield=currentHeaderData[headername];
>+ header = header+headername+": "+headerfield.headerValue+'\n';
>+ }
>+ }
>+
>+ var contractid = "@mozilla.org/widget/clipboardhelper;1";
>+ var iid = Components.interfaces.nsIClipboardHelper;
>+ var clipboard = Components.classes[contractid].getService(iid);
>+ clipboard.copyString(header);
>+}
>+
> // createnewAttachmentInfo --> constructor method for creating new attachment object which goes into the
> // data attachment array.
> function createNewAttachmentInfo(contentType, url, displayName, uri, ...

cancelled ancient review (which apparently I don't know how to do cleanly)

Created attachment 8693516
Unbitrotted patch.

I found this bug looking for "patchlove". I refreshed the patch.

This is the result:
from: =?UTF-8?Q?J=c3=b6rg_Knobloch?= <email address hidden>
subject: some subject
to: <email address hidden>

Pretty ugly:
- The headers need to be RFC 2047 decoded.
- lowercase in the field names.

So the question is, before I invest more work here: Does anyone want this? If not, we mark it "wontfix" and be done with it.

The nice add-on "HeaderToolsLite" also gives access to the headers, you can even edit them.

Created attachment 8693520
Screenshot.

Maybe better: "Copy Email Headers"?

(In reply to Jorg K (GMT+1) from comment #43)
> Created attachment 8693516
> Unbitrotted patch.
>
> I found this bug looking for "patchlove". I refreshed the patch.
>
> This is the result:
> from: =?UTF-8?Q?J=c3=b6rg_Knobloch?= <email address hidden>
> subject: some subject
> to: <email address hidden>
>
> Pretty ugly:
> - The headers need to be RFC 2047 decoded.
> - lowercase in the field names.

That sounds doable?

> So the question is, before I invest more work here: Does anyone want this?

Definitely yes. 17 votes, 8 duplicates across many years. And it's just a freaking annoyance if any relevant text content which is right in front of me cannot be copied and reused for other purposes. Email addresses clearly qualify as relevant text content. Subject is already copyable.

> The nice add-on "HeaderToolsLite" also gives access to the headers, you can
> even edit them.

Thanks for the pointer. Ability to copy relevant text content should be core functionality.

Comment on attachment 8693520
Screenshot.

I think "Copy Message Headers" would better fit to other account types like newsgroups.

Having a menu command for copying the entire header as a block is certainly a big step forward, but in the long run I'd actually expect to be able to select any amount of header text in-place, right there in the actual headers (like for subject now).

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #45)
> That sounds doable?
Anything is doable (I can even fix 15 y/o bugs like bug 26734).

> Definitely yes. 17 votes, 8 duplicates across many years.
OK, I'll continue. Now is the time to do it, since it has string changes.

> Thanks for the pointer. Ability to copy relevant text content should be core
> functionality.
OK.

(In reply to Richard Marti (:Paenglab) from comment #46)
> I think "Copy Message Headers" would better fit to other account types like
> newsgroups.
Thanks, will do.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #45)
> Definitely yes. 17 votes, 8 duplicates across many years. And it's just a
> freaking annoyance if any relevant text content which is right in front of
> me cannot be copied and reused for other purposes. Email addresses clearly
> qualify as relevant text content. Subject is already copyable.

I've thought about this a little over lunch.

I don't think a "copy all headers" function is useful. I've just done it again and this is what I got on a message from the "dev-platform" mailing list.

subject: Re: Dan Stillman's concerns about Extension Signing
references: <email address hidden> <email address hidden> <email address hidden> <email address hidden> <email address hidden> <email address hidden> <email address hidden> <email address hidden>
newsgroups: mozilla.dev.platform
from: Gijs Kruitbosch <email address hidden>
to: <email address hidden>

OK, it can be sanitised down to:

Subject: Re: Dan Stillman's concerns about Extension Signing
Newsgroups: mozilla.dev.platform
From: Gijs Kruitbosch <email address hidden>
To: <email address hidden>

Which average user would want an indigestible block of headers? I think those headers are for geeks. The normal user wants to copy what he/she sees.

Since you can already copy the subject, in my opinion the following would be useful:

Fix the "Copy Email Address" function to copy *all* the text that one sees. Instead of copying
  <email address hidden>
it should copy the full header:
  Gijs Kruitbosch <email address hidden>

It's happened to me so many times that I wanted to copy someone's name (and e-mail address). It wouldn't have helped in the slightest to place a big chunk of data I didn't need onto the clipboard since I wanted to paste the name inline.

So should we close this bug here as "wontfix" and open another one to fix copying the e-mail address?
For the record, the function CopyEmailNewsAddress is here:
https://dxr.mozilla.org/comm-central/source/mail/base/content/msgHdrViewOverlay.js#1625

Or leave "Copy Email Address" alone and add "Copy Email <looking for a good term here>":
Copy Email Details
Copy Email Persona
Copy Email Identity
Copy Full Email Address
Copy Name and Emails Address
Copy Address Header Info

(In reply to Jorg K (GMT+1) from comment #49)
> Fix the "Copy Email Address" function to copy *all* the text that one sees.
> Instead of copying
> <email address hidden>
> it should copy the full header:
> Gijs Kruitbosch <email address hidden>

I'm too for only changing to copy the whole email with name and address. All other headers can be copied with right click.

If someone, or the geek, wants to copy all headers he can open the message with CTRL + u and then select what he want.

Sorry, this is the first bug I'm de-assigning myself from. Not because it's too hard but because it's not useful. It would be a geek feature and personally I don't see what it would be good for.

I'd like to mark this one "wontfix", but last time I did, hell broke loose.

There is bug 327621 which I could fix with one of the options I mentioned:
1) Change existing copy function 2) Have another menu item (wording?).

Richard, do you prefer to change the existing "Copy Email Address" function or have another menu item?

(In reply to Jorg K (GMT+1) from comment #52)
> Sorry, this is the first bug I'm de-assigning myself from. Not because it's
> too hard but because it's not useful. It would be a geek feature and
> personally I don't see what it would be good for.

Thank you for looking at the bug, but I don't understand your reaction. How is wanting to be able to select text and copy it "a geek feature"? The only thing I can think of is because you're trying to solve the problem in the wrong way, using a complicated geeky menu system.

> I'd like to mark this one "wontfix"

Why?

> There is bug 327621 which I could fix with one of the options I mentioned:
> 1) Change existing copy function 2) Have another menu item (wording?).

This looks like the same bug for a different component. It also asks to make the text selectable.

> Richard, do you prefer to change the existing "Copy Email Address" function
> or have another menu item?

I think most people who have commented in this and related bugs see menu options as being second best. If the text is selectable you don't need several options for the different combinations of bits of address that you might want to copy, you can just select the bit you need.

I think this bug has it's merits, you'd just select and copy what data you want. For a xul widget that might be hard, but for an html widget it'd be quite natural.

I often find I'd like to copy all the mailboxes listed, a single one is of less value.

For 327621, I think the current address only should stay, though we should figure something out for "full mailbox".

(In reply to Roger Lynn from comment #53)
> Thank you for looking at the bug, but I don't understand your reaction. How
> is wanting to be able to select text and copy it "a geek feature"? The only
> thing I can think of is because you're trying to solve the problem in the
> wrong way, using a complicated geeky menu system.
I've just looked at the initial patch from 2005. This places a lot of (ugly not useful) data onto the clipboard.

In comment #47 Thomas said:
> in the long run I'd actually expect to be able to select any amount of header text in-place
While this is desirable, it's also hard to do right now. So I'll leave this bug for now and fix bug 327621 instead.

(In reply to Jorg K (GMT+1) from comment #55)
> In comment #47 Thomas said:
> > in the long run I'd actually expect to be able to select any amount of header text in-place
> While this is desirable, it's also hard to do right now. So I'll leave this
> bug for now and fix bug 327621 instead.

Only that this bug 167010 and bug 327621 are duplicates, so you'll still be working on the same thing... ;)
Adding context menus for copying is here:
Bug 99997 - [SM] "Copy email address" doesn't copy name
Bug 232021 - name should be included with email address when copying from header menu

While waiting for this to be fixed could we have a button "new email to all recipients", possibly behind the "more" menu/button, since that probably is one main use of the copy feature.

By the way, the workaround to open the source and copy / paste from there does not work well when UTF8 characters are involved.
Pasting what is copied from the message source into the address field does not convert the encoded character back, it shows the encoding.

(In reply to Samuel Åslund from comment #57)
> While waiting for this to be fixed could we have a button "new email to all
> recipients", possibly behind the "more" menu/button, since that probably is
> one main use of the copy feature.

Thanks Samuel, but, hmmm, probably not. Have you tried using
"Reply All" (Ctrl+Shift+A) or
"Edit as New Message" (Ctrl+E), then remove msg body and attachments)?

> By the way, the workaround to open the source and copy / paste from there
> does not work well when UTF8 characters are involved.
> Pasting what is copied from the message source into the address field does
> not convert the encoded character back, it shows the encoding.

Yeah, source it's an animal of its own, there might well be shortcomings there. Please file bugs if they haven't been filed yet.

Yea, I realized that edit as new works for my purposes after writing the above comment.

The show source feature displays things correctly, UTF-8 characters should be encoded during transmission and thus should be encoded in the source but the address input field does not handle that kind of encoding.

Is there any way to add this workaround to these bugs in a little more visible location?

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

Ryan, Alex, Henry - FYI wrt 114.
10+ duplicates atm, and 42 users CC'ed.

If we could have a similar UX as in composition (easily selectable recipient pills), that would support this basic workflow for many users and avoid clumsy workarounds in 2023 (see user story for more).

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

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

For an impression how much users want to select and copy from inbound message headers, see the ancient parent bug:

Bug 61497 - [SM] Can't select text in message headers / copy subject

**42 duplicates** were filed against that bug, most of them demanding that *all* of the headers should be selectable for copying, i.e. including *recipients*. However, bug 61497 only fixed half of the problem (selecting subject), the other half was moved to this bug 167010 (originally `SeaMonkey`, then `MailNews Core`, now `Thunderbird`).

There are still plans to update the message header recipient list along the lines of https://bugzilla.mozilla.org/attachment.cgi?id=9243994&action=edit I'm not aware of an open bug for this specifically.

Bug 1752532 is introducing new multi-selection widgets that we plan on using for the recipients list (specifically, the "grouped list" widget). I'll block on this for the time being.