Closed Bug 61497 Opened 24 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.2alpha

People

(Reporter: sspitzer, Assigned: sspitzer)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ue1])

Attachments

(3 files)

Attaching storm.gif to this bug (don't know how long it will last on the original site...)
126.09 KB, image/gif
Details
Proposed patch
4.91 KB, patch
Details | Diff | Splinter Review
Example of removing static header pane
38.99 KB, image/gif
Details 
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*.
Keywords: mozilla1.0
Hardware: PC → All
reassigning to mscott and nominating.
Keywords: mail3
> reassigning to mscott

Didn't work. Fixing for you.
Assignee: putterman → mscott
marking nsbeta1+
Keywords: nsbeta1
Whiteboard: [nsbeta1+]
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.
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [nsbeta1+] → [nsbeta1+ 1/25]
Target Milestone: mozilla0.8 → Future
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
Keywords: 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.
Keywords: nsdogfood → nsCatFood
*** 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.
Keywords: 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.
Keywords: 4xp
Oops.. Sorry, wrong bug...
nominating for nsbeta1.  If this depends on new XUL work, shouldn't there be a
dependent bug filed?
Keywords: nsbeta1
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. ***
Status: NEW → ASSIGNED
Keywords: mail3, nsbeta1 → nsbeta1-
Whiteboard: [nsbeta1+ 1/25]
*** 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. ***
Attached patch Proposed patch — — Splinter Review 
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.
Keywords: patch, review
*** 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 bzbarsky@mit.edu  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 bugzilla@uxp.de  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?
Blocks: 23114
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. ***
Keywords: nsbeta1- → nsbeta1
Whiteboard: [ue1]
*** Bug 160686 has been marked as a duplicate of this bug. ***
Blocks: 160730
*** 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: 22 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. ***
Product: Browser → Seamonkey
Summary: can't select text in message headers / copy subject → [SM] Can't select text in message headers / copy subject
See Also: → 167010
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: