Closed Bug 61497 Opened 20 years ago Closed 18 years ago
[SM] Can't select text in message headers / copy subject
I'm unable to select any text in the message headers. for example, I like to select the email address at time to paste into bugzilla for a cc. endico did some investigation and found it had something to do with toolbars. the text in toolbars is not selectable, and we show the headers in toolbars. we might need a special toolbar class (defined in messenger.css?) that would allow text selection. I'm not toolkit expert, but there might be C++ work as well. cc'ing hyatt and evaughan since they'd know what would be involved.
QA Contact: esther → stephend
*** Bug 26367 has been marked as a duplicate of this bug. ***
hyatt once said, we should use CSS |user-select: text|. However, the problem with that is that once a prarent sets |user-select: none|, no child can override that. Thus, if my assumptions are correct, the problem with fixing this bug is to find the right node which sets |user-select: none| and specifically override this to |user-select: text| *on that node*.
reassigning to mscott and nominating.
> reassigning to mscott Didn't work. Fixing for you.
Assignee: putterman → mscott
moving to mozilla0.8 milestone.
Target Milestone: --- → mozilla0.8
*** Bug 64796 has been marked as a duplicate of this bug. ***
marking nsbeta1-. From talking to mscott, it sounds like this is not possible with the current widget set.
putterman, this is wrong. See my comment at 2000-11-29 15:25. Please reevaluate - this is bugging many users quite a lot.
But your comments on 11/30 say it didn't work. mscott can add more comments about the feasibility.
> But your comments on 11/30 say it didn't work. The *reassignment* didn't work.
This really makes certain tasks in email difficult. I have to switch to Netscape Communicator 4 to do certain types of email activity. please do not suggest that I should view source while using NS6 to get the lines I want. keying nsdogfood
I strongly agree with ben. I often am required to copy stuff out of message headers. Mozilla makes this very painful.
*** Bug 71475 has been marked as a duplicate of this bug. ***
*** Bug 74761 has been marked as a duplicate of this bug. ***
converting nomination to nscatfood - there is a workaround for this bug so it isn't dogfood.
*** Bug 75367 has been marked as a duplicate of this bug. ***
There is now a right-click context menu item "Copy" on email addresses in message headers. Does this satisfy anyone? :-) Gerv
Not really, because we also need to be able to copy the subject line - or actually WHATEVER we want to copy. All line in the header should be mouse selectable :) BTW, the context menu on 2001-04-20 has: - add to AB - compose mail to - (C) what is (C)? is that the copy? Someone should edit that menu to read "Copy"!
Peter, that has already been fixed in bug 77096.
OK, but that still doesn't solve the main issue of being able to select *anything* in the header ;)
Gerv: I have to agree with Peter Lairo and answer "no" to your question : it is sometimes very useful to select only the domain part of an address or only a part of the subject line or... Most of MUAs allow such a selection and, just to say it, previous versions of NS have _always_ offered that feature.
It doesn't solve the main problem, but I do believe it makes this better given that we don't have any immediate solution for the real problem. Most of the complaints I've heard are about not being able to copy email addresses so I think this really helps. So, I think this will make it better for a lot of people.
I often want to copy the subject etc.. (Note that we have exactly the opposite situation of 4.x now: In 4.x, the email addresses were fancy links and thus hard to copy. ;-) )
you guys can comment in this bug about how important you think it is all you want but until XUL supports selection it's just not going to happen. =) I'd suggest pushing all your comments on the XUL guys encouraging them to allow us to support selection across xul elements. until that day this bug isn't going to get fixed.
shouldn't this be assigned to a xul person then?
mscott, *I* don't need to select cross element. I just need to select each of the values of the fields. E.g. select subject and date individually (if possible also author and recipients). (Other may want to select the whole table, dunno.) I asked on a newsgroup and hyatt said this were possible, see discussion above. Otherwise, what Dawn said.
I'd like to have this fixed the 4.x way by having the headers part of normal scrollable message text... It's the right thing to do anyway: 1. brief headers are already visible in the message list 2. full headers take too much space from scrollable area
*** Bug 79936 has been marked as a duplicate of this bug. ***
*** Bug 84452 has been marked as a duplicate of this bug. ***
10 dups. Marking mostfreq.
*** Bug 88173 has been marked as a duplicate of this bug. ***
I see that this is a long standing probem, but would like to add my 2p worth. I more often like to select part of the subject line of an email or news message. This is easily done in NS, so my vote would be to make mozilla behave in the same way - have the headers in the message. I do like the 'copy email address' function (which NS doesn't have - it has 'copy link location' which sticks all sorts of 'addbook'**** in there). Max.
Oops.. Sorry, wrong bug...
nominating for nsbeta1. If this depends on new XUL work, shouldn't there be a dependent bug filed?
If it requires selection and a context menu it should be a readonly textbox, possibly in this case with styling to ensure that it still looks like regular text. I don't see what xul work is needed here.
hewitt's told me on several occassions that xul does not support text selection. Is that not true blake?
<label> and <description> do not support text selection, but readonly <textbox>es do, and that's what this should be using if the text is to be selectable (e.g. see OE's standalone message window header).
do readonly text boxes wrap content like labels do? That's one of the reasons why we use label today.
many of our email address headers aren't just text widgets (i.e. the to, cc, bcc lines which contain many email-address node widgets). Can you insert items into a readonly text box like you can insert dom elements into a label and have them wrap and still support selection? I didn't think it could do that but maybe I'm wrong.
*** Bug 115218 has been marked as a duplicate of this bug. ***
*** Bug 116547 has been marked as a duplicate of this bug. ***
*** Bug 117116 has been marked as a duplicate of this bug. ***
*** Bug 117331 has been marked as a duplicate of this bug. ***
*** Bug 117487 has been marked as a duplicate of this bug. ***
*** Bug 121581 has been marked as a duplicate of this bug. ***
*** Bug 122736 has been marked as a duplicate of this bug. ***
*** Bug 125863 has been marked as a duplicate of this bug. ***
I attached this patch to another bug some time ago :-( It converts non-email fields to readonly plain inputs. It doesn't make email lists selectable, it just allows them to wrap internally.
*** Bug 126890 has been marked as a duplicate of this bug. ***
*** Bug 128228 has been marked as a duplicate of this bug. ***
*** Bug 134926 has been marked as a duplicate of this bug. ***
*** Bug 139527 has been marked as a duplicate of this bug. ***
This is bothering a *lot* of users! If fixing bug depends on the XUL guys, because some widgets don't allow that functionality , and the XUL guys can/do not fix it, why not displaying the headers as part of the text message -- same as 4.x does? That's the right thing to do *anyhow*!! Why that extra grey box for the headers?? It's simply *annoying*! Here's another example where this is crucial: - try to send somebody a cut+paste of a forged email header.. not with Mozilla! And "view Message source" is not a work-around - it's just a lame excuse for not fixing this.. :P If so many users need that feature, then this should be solved one way (better widgets) or the other (headers as part of the message)
Just chiming in to say i agree this is a pretty severe shortcoming of basic copy-paste ability. I personally like the aesthetics of the gray message header, but putting the header in the text area in 4.x fasion (while whatever XUL issue gets worked out) is better than not being able to copy text from the head.
You can also have a look at my suggestion in bug 117322. If you like it, you can give it a vote.
*** Bug 141878 has been marked as a duplicate of this bug. ***
This bug is reminiscent of bug 60513, which applies to alert box text. I don't know if it uses a toolbar class, but if a generic class is implemented that would allow me to selet any text, I'd be more than happy to let the bug piggyback here. Is there ever a valid reason to disallow selecting text?
> Is there ever a valid reason to disallow selecting text? Yes. It looks _really_ bizarre if all text in the UI is suddenly selectable.. Consider selectable text in the menubar, for instance...
> ------- Additional Comments From email@example.com 2002-05-05 19:51 ------- >>Is there ever a valid reason to disallow selecting text? > > > Yes. It looks _really_ bizarre if all text in the UI is suddenly selectable.. > Consider selectable text in the menubar, for instance... What an excellent idea! IMO, *all* text that is visible should be selectable. I find it extremely irritating that you can select text when there are error message windows on top, for example - and you often can't select error messages in those windows. How much simpler it would be to be able to select all text, no matter where it is displayed. Perhaps you could explain what you mean by 'bizarre'... Max.
bizarre : Strikingly unconventional and far-fetched in style or appearance; odd. Eccentric, freakish, freaky, flaky, outlandish, outre. If you want text to be selectable everywhere in the application please file a different bug.
> ------- Additional Comments From firstname.lastname@example.org 2002-05-06 00:18 ------- > bizarre : Strikingly unconventional and far-fetched in style or appearance; odd. > Eccentric, freakish, freaky, flaky, outlandish, outre. > > If you want text to be selectable everywhere in the application please file a > different bug. No - that would be unrealistic. My point was that being bizarre is not a good enough argument to not having the functionality - especially in this case, and doubly so since previous email clients allow selection of header items and do not look (IMO) "bizarre". Max.
I saw something neat in the Chatzilla UI. When you doubleclick the topic, it converts into a edit box. If we did the same in the mail window header area, this would have to be a read-only edit box, of course. The edit box changes back to a static text field as soon as you click somewhere else.
Max: if _all_ text in the entire UI was selectable, that would be very "bizarre" - a slip of the mouse, and you might find you'd selected the text in a menu item or on a button, which would make most users think the application was falling apart. That's reason enough not to do that - you said yourself that it's not realistic. what's desired is having a few bits of text selectable - including these message headers. Don't think anyone is saying what is needed for this bug is bizarre, just that the suggestion that all text in the UI be selectable was.
Firstly, let's try to keep all comments to this bug relevant and useful. Please do not comment if you are offtopic. The right way to fix this is not to add some ad-hoc textbox that will suddenly appear if the user randomly tries to click on a label. We shouldn't do that for lots of reasons, but mainly because it's totally inconsistent with our usage XUL toolkit. Moving on, here's a proposal on how to fix this bug: mailnews, like many other email readers, could just simply embed the message headers to the top of the message. That would not only be a simple way of doing it, it would also fix a bunch of other bugs about our current XUL message headers; speed up message loading; make all text *naturally* selectable in the message, just like any other text; and we would - as mentioned - be consistent with most other email readers. Also, the proposal would fix another long-standing bug where message headers should be scrollable in the message, like the rest of the text. mscott, sspitzer, jglick and others: does this sound like a feasible solution?
How does that proposal interact with toggling between full header view and short header view?
This is the "Select a Directory" dialog. So there are two things "selected" can mean: 1) Visually selected (eg after being clicked on) 2) Selected as in "this is the directory I pick" The "Selected" button implies the second meaning (the wording may need improvement to clarify this). It is the default button. It dismisses the dialog. The only reason to click the "Open" button (which could also be called "Descend" if we _really_ want to confuse users.... :) ) is if you don't want to double-click a directory in the list but do want to descend into it.
We should certainly clarify the wording, and position the buttons correctly for platforms that have a standard place for default buttons.
I tend to think that the message header should be selectable by selecting upwards from the middle of the message text.. that way, it makes sense (looks like an email) when it is pasted somewhere else. Mozilla copies the way that outlook express does it by having a static area above the message with the message header in it, and since microsoft's UI decisions seem to please the masses then maybe we should allow both, and just let the user select which style they want ?
Has anyone considered making the currently static area that we're complaining about the same as the header that shows for embedded emails in MIME sections within the main message ? It looks reasonable.. has background colour and formatting to make it obviously a message header, but is also just part of the message and is scrollable and selectable. Alternatively, mozilla could go with the way Kmail currently does it: http://www.theregister.co.uk/media/797.png (a box within the message .. almost the same as an html table - selectable of course.. within the message, containing the header info)
Yes, I proposed that long ago (can't find where). It should generally quite easy to implement: Just change the URL or the mimetype of the message loaded in the msg pane. There are some things to consider, though, which mainly evolve around the fact that these grey headers are in the msg sandbox which renders the msg body, which is remote content and thus very restricted in what it is allowed to do. Often, not even JS is allowed to run there. (I am assuming that we'll linkify email addresses (probably as mailto:) in the headers.) - Context menu - "Add to Addressbook", "Compose Mail To" could be added to the standard context menu for mailto: - Same for any AIM menu items Netscape 6 might have. - "Copy Email Address" is already part of that context menu. - "Create filter based on this message" and a possible future "Reply to this recipient" might be a problem, however, since the mailto: URL has no information about the msg. - Different versions of headers The "abstact" (one-line) version of the header section probably can't be implemented this way in the msg sandbox, because of the absense of JS. A View|Headers menu item should be possible, though. Scrollable headers will remove much if the need for this version, too. - Attachments What do we do with the attachments box?
I should point out that I do like the static header bar (because I use standalone msg windows, which have enough vertical space). The listed problems should also show that such an approach potentionally make future features much harder to implement. It is up to the Mailnews FE developers to decide about that.
The suggestion for removing the static header looks like a big change to me. For example, we also display icons in that header area, visualizing the encryption/signature status of the message. Because that information is not known in advance, but while the message is analyzed, it would mean, that we have to modify the displayed message contents on the fly... I think we should try to find a simpler solution. Idea 1: Would it be possible to have a right click menu on each shown text label, containing a single menu item "copy"? Idea 2: I think that using "view message source" is an acceptable workaround. The point is many users never saw that menu item. We could have a tooltip on the header area, that gives a simple hint (use View/Message Source to copy). Idea 3: Could we just extend the list of menu items in the Edit menu? Could we have new items for - copy subject - copy message headers ? This also could be combined with a tooltip, to hint those people who try to use the mouse to select and copy. They probably would see the tooltip message.
Kai: 0. the big problem is that the headers can take more vertical space than is available, they aren't scrollable. 2. it isn't. 3. that's awful. re your concerns, um, mozilla modifies lots of things on the fly, ... however imo encryption status doesn't belong in the headers, it belongs in the frame.
Then maybe it should collapse the headers automatically if there's not enough space. And I really like the rightclick copy idea...
If people like 2.) (right-click-menu-copy-on-labels), then we should implement them. This would be a great help in many places. For example, sometimes the UI shows lengthy error messages, and users want to let other people know about that error message. Currently, they have to remember that (which leads to communication errors) or write it down (which many users don't want to). It would be really cool if right-click-copy would work on any label in the UI.
I vote for 2) too. That's a wonderful solution, and having it globally in the whole UI would be a totally wonderful, innovative thing, not seen before in any software.
Just to clear up some numbering confusion: We are not talking about 2.) I think we are talking about idea 1.) from comment 74 - the right-click-menu-copy on text labels.
Yes, I've meant 1) too.
As long as the right-click to copy addresses remain, and there is a "Copy all headers", I think that could work. Still doesn't solve the non-scrolling bug. Is that another bug-number?
The vast majority of users aren't going to discover 1 or 2, and 3 doesn't extend well, and complicates the UI unnecessarily. Using a tooltip to tell people how to access 2 is a dead giveaway that the UI is bad, just like doors that have a pull handle, but open with a push, and therefore need signs that say "Push". People who want to select in the headers should find that the normal means of selection just work, and not have to use convoluted workarounds.
Why is it then that we can't use the same input fields (readonly, no border) as in the page info fields? It is the same as in other parts of the UI, and the same as in many other parts of (at least) windows (Win2k, IE, Office, Corel draw etc).
Because they do not wrap. See comment 40. Which you _did_ read as you read the whole bug before commenting, right?
I totally agree with Trudelle's comment. The point of this bug is that people want to be able to physically select the pieces of header information they need, the same way you can select text in a text document. No right-clicking context menus; no easter-egg tooltips; just a plain way to copy and select message headers. Let me re-iterate the benefits of putting the message headers in the message (where the belong in the first place, IMO): - Message headers are selectable the normal way. - Message headers are scrollable; emails with many "To:" or "Cc:" recipients will finally be readable, and the headers won't take up all the message pane space. - I think it would speed up message loading (since we removed the XUL headers bloat) - It would make the message pane larger by default - making emails easier to read on screens of all sizes. In response to Kaie about the secure message concern: we could simply make the message icon in the threadpane have a "lock" on it, or create an additional column that would indicate when a message is secure. That would be consistent in what we do in for example newsgroups, with ignored/watched headers.
Re: previous comment #85 And one more benefit: - URLs in the headers (e.g. in Subject) would finally become clickable links (as bug 23114 asks).
> URLs in the headers (e.g. in Subject) would finally become clickable links No, they wouldn't any more than now.
I've kind of grown to like the fixed position, and *always readable* header. Much of the mentioned problems would be solved if: 1. The header text were freely selectable (this bug) 2. Limited vertical Space problem: If bug 60207 comment #19 (View/Headers/Brief) were fixed the header would only take up 2 lines! +-----------------------------------------------------------------------------+ | Subject: This must have enough space for looong subjects |Attachments || | From: YoMama Date: 31.12.2929 at 16:45 |______________|| +-----------------------------------------------------------------------------+ | |
*** Bug 144776 has been marked as a duplicate of this bug. ***
*** Bug 144825 has been marked as a duplicate of this bug. ***
*** Bug 144993 has been marked as a duplicate of this bug. ***
*** Bug 145095 has been marked as a duplicate of this bug. ***
*** Bug 146019 has been marked as a duplicate of this bug. ***
OK, I'll bite, why is it necessary for the headers to wrap? It only wastes space.
> why is it necessary for the headers to wrap? Check the summary of this bug: "can't select text in message headers" Now, suppose the headers didn't wrap. Suppose the headers you wanted to copy were several times "wider" than your current window. Imagine selecting that text. > It only wastes space. Some form of progressive disclosure might be appropriate. Saying that it "only" wastes space ignores the purpose of this bug. It is true that a tradeoff will be involved, but tradeoff's aren't "only" sorts of things; they're "this but then that happens" sorts of things. -matt
Assuming attachment 70284 [details] [diff] [review] is used: To select text in a very long header: Right click, Select All. Or click in the text and drag through. The tradeoff is that you only see the first line of the header, without any useful indication that some of the header is not visible.
*** Bug 151172 has been marked as a duplicate of this bug. ***
Once again: having access to *unmodified* headers is crucial!! Especially for postmaster and sys-admin folks, but also to figure out how to filter SPAM(TM) and for many other reasons. Pre-processed headers are simply a *nuiscance*!!!! Not to talk about not being able to cut and paste in the current implementation of the headers - which *sucks* Netscape 4.x style header display is way way better..
> Especially for postmaster and sys-admin folks These are the folks for whom "view message source" exists. The vast majority of people (including admins) do _not_ want to see all the "Received:", etc, headers on every single message all the time. Some of them want to get to it if needed. The rest never want to see that info.
Just wanted to reply to Boris' assumption that selecting the subject for copying is restricted to admins, or techy kind of users. This is simply not the case, as is evident by the large number of comments on this bug. One user I had installed Mozilla to handle mail for immediately was struck with this bug. He runs a news site, and gets a lot of press releases in from a variety of different places. The vast majority of the time, the subject of these e-mails will become the headline on his site. Anywhere from 10-20 messages like this every single day. Viewing the source code never occurred to him. Even after showing him this, it was simply too time consuming. This was a major show stopper for him. Admins and otherwise technically knowledgable people are not the focus of this bug. These kinds of folks will dance right around this in moments. Try showing some non-techy users the source code of their E-Mail, and watch their eyes glaze over. It's honestly scary for them.
> Boris' assumption that selecting the subject for copying is restricted to > admins, or techy kind of users. Um.. I never said that. I said full access to unmodified headers (per comment 98) is for admins and techy users. I fully agree that the headers we _do_ show normal users should be copyable. And I wish people in this bug would focus on that....
Boris, my apologies. I misread your statement. Still, I did want to mention this one user who was impacted by this. He's now using KMail these days and is quite happy with it.
*** Bug 152801 has been marked as a duplicate of this bug. ***
Look at bug 128809 - can't they both be fixed together by turning the geaders window into a scrollable, resizable textarea?
*** Bug 155008 has been marked as a duplicate of this bug. ***
*** Bug 156062 has been marked as a duplicate of this bug. ***
The headers for a message inside another message are displayed as selectable text, which means that if you forward a message to youself, you can then select the text easily. (Yeah, you can also select it in the document source, but that's not my point) Why can't the main header simply be displayed in the same way that inline ones are ?
Ian Batterbee, you asked the *same question* 2 months ago, and I gave a long answer. Scroll up (or down), please. Which game is that??
So you did. I had forgotten. And since then, no progress seems to have been made on this problem. What has to happen to actually get a fix ? There have been a number of suggestions, most of them with drawbacks, but I hardly consider the current implementation to be without drawbacks itself. Are we trying to get a consensus before anything can be tried, or are we all expecting someone else to submit some code ?
*** Bug 156904 has been marked as a duplicate of this bug. ***
*** Bug 160686 has been marked as a duplicate of this bug. ***
*** Bug 160993 has been marked as a duplicate of this bug. ***
*** Bug 161639 has been marked as a duplicate of this bug. ***
*** Bug 162233 has been marked as a duplicate of this bug. ***
OK, this bug and pretty much this bug alone is causing me so much grief that I am no longer going to use Mozilla as a mail or news client. Max.
For the record, I'm moving to Mac OS X 10.2's Mail client, which does allow me to select message headers.
Summary: can't select text in message headers → can't select text in message headers / copy subject
taking from scott. part of neil's fix for this is included in the patch for http://bugzilla.mozilla.org/show_bug.cgi?id=91662 this should land for mozilla 1.2 neil, thanks again! sorry I've let your fix for this (And 91662) rot since 2-19-2002.
Assignee: mscott → sspitzer
Status: ASSIGNED → NEW
Depends on: 91662
fixed. the fix for this was in bug #91662
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.2alpha
I'll logged a new bug about allowing similar select / copy of email addresses (instead of one at a time, right click copy) see http://bugzilla.mozilla.org/show_bug.cgi?id=167010
Build ID: Mac OS X 10.1.5 / Mac OS 9.2 - 2002-09-06-08 Windows 2000 - 2002-09-06-08 RedHat Linux 7.3 - 2002-09-06-08 Themes: Classic / Modern. Header Views: All / Normal, including the collapsed 'mini-header' style. Headers Tried: From, Date, To, Return Path, Received, Message-ID, User-Agent, X-Accept Language, MIME-Version, Content-Ttype, and Content-Transfer-Encoding Operations Tested: Copy, paste, select all, scrolling via mouse and keyboard. I'll have to investigate and file on: Lack of blinking caret / cursor. (Maybe this is a limitation of the widget's style). Also, keep in mind Seth has filed bug 167010. Please direct future comments / questions to either that bug, or newly filed specific ones. Verified FIXED.
Status: RESOLVED → VERIFIED
yes... "cut&paste" bug is, strictly speaking, solved.. But the solution is half baked. Here is why: - I do send many times "spam complaint" to the originator ISP. - many times they want to get the complete e-mail header (yes, I know.. forward does the trick... but not always...I've got many times from ISP's postmaster: please send the header... I do not want to go into details if that particular postmaster was competent or not... fact of the matter is, they asked me to send the complete heeader) - so, what I am doing ? I do grab the complete header with the mouse and paste it into the e-mail for the offending ISP - your current solution DOES NOT allow me to do that. I can grep one item at the time and paste it into the e-mail. This is very annoying process (Yes, I know... I could open the page source and cut&paste it from there.. but... this still does not solve the problem... the process is still very unfriendly) So, the question and suggestion is very simple: Why don't you implement the solution from old Netscape Messanger ? This is, for me, the main reason I am still using Netscape Messanger as my primary e-mail client And one more thing: Header, seen from the mail client, DOES NOT contain multiple "Receive:" lines.... and because of that, the "cut&paste" has one bug more... (aka... the solution is, as I said at the begining, _____half baked________
Independent from the bug I have a suggestion of a work around: view message source (ctrl + u) and copy & paste the code there. Joerg
yes I know .. I could do that... changing topic I was using wrong words.. I am talking here about "copy & paste" and not "cut & paste" Sorry for confusion :(
Re: comment #121 I completely disagree. If you want complete headers, just do "view message source", or select "View Headers -> All" and then "Message -> Forward As -> Inline". The "received" lines are only meant for "advanced" users and "advanced" users should be comfortable using advanced tools...
You're still unable to select several lines at once, the header name etc. That isn't a critical feature, but quite unnecessary limitation. Is there some serious reason users couldn't be able to select the name of the field they are copying contents from, or two header lines at once? Plain nsCatFood issue I think.
File a new bug if you want to extend the behavior. This bug is fixed.
Did so. The bug has been registered as Bug 169027 Everyone not fully satisfied satisfied with current solution, please move your votes/work/comments/CC there.
*** Bug 169803 has been marked as a duplicate of this bug. ***
In addition to my comment 72: Someone just sent me a screenshot of a 'problem' he has with Mozilla 1.3a. Seems like he has exactly what some people here would like to see. From <http://www.fischenich.org/mozilladriss.gif>.
(I didn't want to reopen any discussions, just to illustrate what I talked about back then. Note that this bug is marked fixed.)
*** Bug 160865 has been marked as a duplicate of this bug. ***
Summary: can't select text in message headers / copy subject → [SM] Can't select text in message headers / copy subject
You need to log in before you can comment on or make changes to this bug.