Last Comment Bug 204350 - (message/rfc822) Attached email message window glitches (forward, reply, view source disabled)
: (message/rfc822) Attached email message window glitches (forward, reply, view...
Status: RESOLVED FIXED
: fixed1.8.1
Product: MailNews Core
Classification: Components
Component: Attachments (show other bugs)
: Trunk
: All All
: -- normal with 55 votes (vote)
: ---
Assigned To: David :Bienvenu
:
Mentors:
: 162646 190673 213320 217382 224967 228790 234998 239980 268453 313978 323319 344115 357576 359531 360497 361882 375079 375478 376872 383435 388010 441427 450561 468226 477566 (view as bug list)
Depends on: 204612 334166 218912 236397 310264 327936 366482 544359
Blocks: 269826 3901 223801 370090
  Show dependency treegraph
 
Reported: 2003-05-03 18:27 PDT by Mike Cowperthwaite
Modified: 2013-10-30 05:44 PDT (History)
69 users (show)
mkmelin+mozilla: blocking‑thunderbird3-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
digested mailing list reveived via email (10.06 KB, text/plain)
2003-12-11 10:57 PST, Robert Marshall
no flags Details
support reply/forward (as attachment and inline) for message/rfc822 attachments (33.58 KB, patch)
2005-10-21 09:08 PDT, David :Bienvenu
mscott: superreview+
mscott: approval1.8.1+
Details | Diff | Review
front end part (876 bytes, patch)
2005-10-27 09:48 PDT, David :Bienvenu
mscott: superreview+
mscott: approval1.8.1+
Details | Diff | Review

Description Mike Cowperthwaite 2003-05-03 18:27:35 PDT
If an email is attached to another message, and is opened (by double-clicking in 
the Attachment list), the new email opens into its own message window, with a 
header pane and a toolbar.  (This is an improvement relative to 1.3.)  The 
headers are correct (unlike the situation described in bug 200380).

However, there are a few things wrong with this window:
1) It shows an attachment -- which is, in fact, the message itself.
2) View|Source is disabled.
3) View|Headers is not disabled, but does not function as expected: the 
displayed message continues to show whatever headers it was opened with.  (A 
non-attachment email opened in a message window will expand/contract its header 
pane to follow selections from its own menu.)
4) Most of the toolbar icons are disabled.  Perhaps this is by design, but I 
don't see why Forward, at least, if not Reply & Reply All, shouldn't be enabled. 
Of course, those functions should act on the viewed (attachment) message, not 
the container message back in the 3-pane.
Comment 1 FZiegler 2003-05-03 21:10:03 PDT
Hardware/OS -> All. (Seeing this on Mac build 2003-04-19-03.)   
Comment 2 Mike Cowperthwaite 2003-05-19 07:24:01 PDT
Symptom (1) of this bug is a duplicate of bug 203570.
The rest of this bug appears to recommend the opposite tack from bug 201881.
Comment 3 Mike Cowperthwaite 2003-07-22 06:48:42 PDT
*** Bug 213320 has been marked as a duplicate of this bug. ***
Comment 4 :aceman 2003-09-25 01:27:38 PDT
Yes, many people suggest the attached message shoudn't be aditable, 
forwardable, editable. Maybe it is really nonintuitive or doesn't make sense.
Is it normal to send someone a reply to a message someone else sent you as an 
attachment? The final recipient may be a bit puzzled. Some people would like 
this feature just for their internal mail management needs.

My suggestion is: if the proposal of disabling everything comes through,
the eml import feature will come handy (bug 193281). If someone still wishes to 
edit an attached message, he can save it to disk, immediatelly import into his 
inbox and edit (reply) it. I think both parties would be satisfied.
Comment 5 Mike Cowperthwaite 2003-09-25 07:42:04 PDT
I could live with that; but I do think  View|Source and Forward are sensible 
functions to execute directly on the attachment.  For instance, you receive a 
message with a forwarded suspect spam/virus email attached; in this case, you 
might want to examine the source yourself, or you might want to forward the 
suspected mail (only) to a designated spam/virus handler.

View|Headers, too, altho overall I favor bug 154712 regarding that function.
Comment 6 Mike Cowperthwaite 2003-11-01 13:49:50 PST
*** Bug 217382 has been marked as a duplicate of this bug. ***
Comment 7 Luke Walling 2003-11-02 07:54:16 PST
What would someone want to reply to a message not sent to them originally for ?

How about sales leads or support emails forwarded as attachments?  I get this
stuff regularly.. I really like thunderbird but it is a *pain* to reply to these
types of emails in it !

It would be great to see the reply button work in forwarded texts.
Comment 8 Mike Cowperthwaite 2003-12-01 13:51:26 PST
Adding dependency on bug 218912 -- that bug notes that Edit As New doesn't work 
for the messagewindow containing the attachment.
Comment 9 Robert Marshall 2003-12-11 10:57:24 PST
Created attachment 137257 [details]
digested mailing list reveived via email
Comment 10 Robert Marshall 2003-12-11 11:01:14 PST
I have seen several instances where it takes Digested mailings, and you have the
main window contain all the text, as well as have several attachments, one for
each email msg. When I click on the attached msg that I want to reply to, I
can't forward it. To do so, I have to cut and paste the correct address, AND
edit the full msg to get what I want to. Definately more work than is necessary.
Fixing this bug would aleviate that. I attached a saved example of one of the
msgs that is experiencing this issue, saved from within Thunderbird. Hopefully,
its intact.
Comment 11 Joe Infla 2003-12-17 10:53:20 PST
*** Bug 228790 has been marked as a duplicate of this bug. ***
Comment 12 Joe Infla 2003-12-17 11:04:50 PST
Also note that Message -> Copy and Move are enabled but nonfunctional.  There
are enough 'glitches' relating to this window that it might be appropriate to
spin off individual problems into separate bugs.

Adding some keywords to summary.  Old summary: 
Opening attached email shows a message window with glitches
Comment 13 Joe Infla 2003-12-17 11:33:46 PST
Adding some such pre-existing bugs to block-list.  Also see bug 76253, whose
comment 9 claims the attached patch will fix view source for attachments.
Comment 14 Mike Cowperthwaite 2004-01-16 15:30:31 PST
Adding dependency on bug 3901:
  "want ability to forward message/rfc822 attachments"
Comment 15 Wolfgang Rosenauer [:wolfiR] 2004-01-17 03:28:01 PST
at least for mailman (list-software) it does make sense to be able to answer
mime parts because mailman attaches confirmation messages to requests and the 
listadmin must be able to answer those mime-attachments.
So I really see the need for at least forward and reply options for mime parts of
multipart messages.
Comment 16 WADA 2004-01-26 19:22:36 PST
Please add "message/rfc822"(at least "rfc822") in summary for ease of search.
(I have no previridges for it)
Comment 17 FZiegler 2004-01-26 19:59:10 PST
Also the "Go -> (Previous|Next) Message" (menu|toolbar|keyboard shortcut) items
are disabled. Dunno how feasible this would be, but: in the case of listserv
digests, having this open the (previous|next) *attached* message could make for
a pretty convenient to "undigestify" on the fly...
Comment 18 WADA 2004-01-26 20:58:02 PST
(In reply to comment #17)
> Also the "Go -> (Previous|Next) Message" (menu|toolbar|keyboard shortcut) items
> are disabled.

This should be, I belive.
Since this is display of "attachment", "previous/next message" has no meaning,
although data format of message/rfc822 is completely same as a mail in a mail
folder except mail separator in unix mbox file is not contained.

I think different window(design/menu-iem/logic/function) should be used for
attached message/rfc822 from real mail display, because message/rfc822
attachment is not a real mail and has both "attached file" and "mail"
characteristics.
And if this type of change will be done, ".eml" file support will be
automatically included in Mozilla Mailnews and Thunderbird.
Comment 19 Asa Dotzler [:asa] 2004-03-09 13:11:22 PST
*** Bug 162646 has been marked as a duplicate of this bug. ***
Comment 20 Mike Cowperthwaite 2004-03-17 14:08:58 PST
*** Bug 234998 has been marked as a duplicate of this bug. ***
Comment 21 Mike Cowperthwaite 2004-04-08 11:49:21 PDT
*** Bug 239980 has been marked as a duplicate of this bug. ***
Comment 22 WADA 2004-04-08 12:42:25 PDT
2004040608-trunk/Win-2K(SP4) always displays message/rfc822 attachment in format
of "Message body as HTML"(I can not say which of Original or Simple),  and
"Display Attachments Inline", and these View menus are killed - can be changed
but display format will not be changed.
Does this bug cover this problem too?
Comment 23 Mike Cowperthwaite 2004-04-21 08:32:29 PDT
See bug 241213.
Comment 24 Moritz Naumann 2004-06-06 16:17:15 PDT
Looking over the *numerous* posts and user requests this topic has generated, it
seems obvious to me that this 'bug' needs a solution which both sides. 

It is obvious that the ideas on the topic whether to have the reply/forward/view
source/... functions for attached/imported emails activated or inactivated are 
diverted. For this reason, I think the best and only possible solution is to let
the user decide and make the more secure setting the default. 

This would mean that the default setting should be that these options are
deactivated for attached RFC822-cmpliant mime-parts but should be activatable by
editing the user preferences config files. I think everybody would be happy with
this solution (except the developers, maybe, as this sounds like a lot of work
to me ;) ). 
Comment 25 Tim Roberts 2004-07-23 14:38:33 PDT
I just don't see the "security" aspect to this.  A message/rfc822 attachment 
is a complete message, with headers.  T'bird knows this, and displays it 
correctly.  It violates the "principle of least astonishment" to treat this 
message any different from any other message in the inbox.  It is a fully-
formed message: I should be able to do to it anything that I could do to an 
inbox message: read, reply, forward, save-as, etc.

If someone does not want to reply to attachment messages, then I strongly 
suggest they not click the "reply" button when viewing one.  It makes zero 
sense to disable the option.
Comment 26 M.J.G. 2004-07-28 04:28:24 PDT
(In reply to comment #25)
> I just don't see the "security" aspect to this.  A message/rfc822 attachment 
> is a complete message, with headers.  T'bird knows this, and displays it 
> correctly.  It violates the "principle of least astonishment" to treat this 
> message any different from any other message in the inbox.  It is a fully-
> formed message: I should be able to do to it anything that I could do to an 
> inbox message: read, reply, forward, save-as, etc.

I second that. It is a power user feature, but harmless for the "unknowing".
For what it is worth, pine does exactly what this bugs requests for
mozilla/thunderbird. An attached e-mail is an e-mail, and you can do with it
what you can do with an e-mail, especially save to a folder and reply. It is one
of the things which makes me go back to pine quite often (others being "bounce"
and "delete attachment"), and which keeps power users (mutt...) from switching
to moz.
Comment 27 Timo Maier 2004-08-31 06:32:34 PDT
(In reply to comment #25)
> If someone does not want to reply to attachment messages, then I strongly 
> suggest they not click the "reply" button when viewing one.  It makes zero 
> sense to disable the option.
Yeah! Give us the freedom to reply to attached mails. PLEASE!
Comment 28 Eugene Koontz 2004-11-11 23:29:46 PST
Can someone briefly explain *how* the disabling of "reply", "forward" buttons,
etc, is implemented? 

I can look at the XUL of the message window with the DOM inspector and see that
the toolbarbutton "button-reply" and see that the "disabled" property is "true"
for rfc822 attachments, but where in the javascript (or perhaps in the C++) of
the mailnews component is this done? 

I'd like to try to help fix or at least understand this bug (and other
message/rfc822 attachment bugs).
Comment 29 WADA 2004-11-11 23:46:03 PST
(In reply to comment #28)
> Can someone briefly explain *how* the disabling of "reply", "forward" buttons,
> etc, is implemented? 

Patch for bug 143565 is probably root of disabling, because bug 143565 is set as
depends on bug of bug 203570, which is opposite one to this bug.  
See Comment #2 From Mike Cowperthwaite.
Comment 30 Eugene Koontz 2004-11-22 00:57:31 PST
Thank you, Wada, for your pointers. The disabling logic is really just one line,
right here :

http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/messageWindow.js#737

Of course, it won't work to simply disable this check. Rather it seems that we
need to somehow allow attached messages to be registered with a key in the gDBView.
Comment 31 Mike Cowperthwaite 2004-12-18 09:37:14 PST
*** Bug 190673 has been marked as a duplicate of this bug. ***
Comment 32 Filip Miletic 2005-05-06 13:01:55 PDT
(In reply to comment #7)
> What would someone want to reply to a message not sent to them originally for ?

For instance, when replying to a message from a mailing list, which was bundled
in a MIME digest (e.g. mailman):

1) The To: is the address of the list, i.e. not-me.
2) This message gets forwarded to me
3) I _want_ to reply to it, and there is nothing wrong about this being possible.


Comment 33 Wayne Mery (:wsmwk, NI for questions) 2005-09-24 16:22:06 PDT
FWIW - Bug 201881 Comment 8 suggests Bug 201881 be marked WONTFIX due to the
number of votes here for this bug, bug 204350.
Comment 34 Mike Cowperthwaite 2005-09-30 09:42:38 PDT
Adding dependency on bug 310264, which wants to be able to print an attached 
message.
Comment 35 wind li 2005-09-30 19:33:09 PDT
In the case you working in a teams,some time when you talking about something,
but you find that some other persons not in the thread are the right persons to
answer some questions, what will you do?
I will forward some mail to him and would like to get him jump in the thread.
Then we need at least let him reply/print the forwarded mails.
Comment 36 David :Bienvenu 2005-10-21 09:08:25 PDT
Created attachment 200351 [details] [diff] [review]
support reply/forward (as attachment and inline) for message/rfc822 attachments 


with this patch, thunderbird supports reply + forward as attachment and inline
for message/rfc822 attachments opened in a stand-alone msg window. It also
fixes some problems displaying inline attachments in those messages, and .eml
files opened from the command line.

It doesn't handle view source or a couple other things, like show all/normal
headers, but it's a step in the right direction.
Comment 37 Scott MacGregor 2005-10-26 15:30:08 PDT
Comment on attachment 200351 [details] [diff] [review]
support reply/forward (as attachment and inline) for message/rfc822 attachments 

+    rv = NS_NewURI(getter_AddRefs(uri), messageURI.get());
+    NS_ENSURE_SUCCESS(rv, rv);
+    if (aURL)
+      NS_IF_ADDREF(*aURL = uri);

Is it ever possible that a user could pass in null for aURL? Is it an optional argument? If it is supposed to be non null, we could check the arg ptr at the beginning of this method and then just pass aURL directly into NS_NewURI.
Comment 38 David :Bienvenu 2005-10-26 16:28:12 PDT
it can and often is null - many callers don't care about the resulting uri. But I need to create one there and open the channel on it...
Comment 39 Mike Cowperthwaite 2005-10-27 09:28:13 PDT
*** Bug 313978 has been marked as a duplicate of this bug. ***
Comment 40 David :Bienvenu 2005-10-27 09:48:13 PDT
Created attachment 201005 [details] [diff] [review]
front end part

forgot this part of all this work - this uses a method on nsIMessenger to get the hdr, because that knows how to use the dummy header...
Comment 41 Mike Cowperthwaite 2005-10-29 14:01:14 PDT
Is any part of the patches for this bug Thunderbird-only, or is it all Core?
The TB bug for this issue is bug 224967.

The fix (as seen in TB 1.6a1-1028) is working about as well as the equivalent
fix for .EML files in a standalone message window:
 - Reply, Reply All and Forward are working; likewise: Edit as New.
 - Print Preview and Print are working, except they show message source rather
than as-displayed, including showing binary attachments in all their BASE64
glory.  (Compare to the same situation for .EML, which crashes on Print.)

See bug 268746 comment 11 and 22.  The symptoms from bug 314349 and bug 314351
apply to this bug's fix.
Comment 42 Worcester12345 2005-11-08 10:28:48 PST
(In reply to comment #41)
> Is any part of the patches for this bug Thunderbird-only, or is it all Core?
> The TB bug for this issue is bug 224967.

I was wondering the same thing when I saw it wasn't "Core", but "Mozilla Application Suite" under "Product". 
Comment 43 Mike Cowperthwaite 2005-11-09 08:04:14 PST
Attachment 201005 [details] [diff] was checked in yesterday; it fixed bug 231282, at least for Thunderbird.
Comment 44 Mike Cowperthwaite 2005-12-12 09:49:03 PST
(In reply to comment #41)
> Is any part of the patches for this bug Thunderbird-only, or is it all Core?

Finally testing with a Seamonkey trunk build (1.5a-1211), all the items fixed here for TB are also fixed in Seamonkey.

>  - Print Preview and Print are working, except they show message source rather
> than as-displayed, including showing binary attachments in all their BASE64
> glory.

I still see this with TB 1.6a1-1201, but Seamonkey 1.5a-1211 handles this correctly.


> The symptoms from bug 314349 and bug 314351 apply to this bug's fix.

314349 is TB-only.  I did some work on another bug recently that made me think the problem in 314351 is just one symptom of a larger problem, unrelated to whether the message in question is an attachment or .EML file.


(In reply to comment #43)
> Attachment 201005 [details] [diff] [edit] was checked in yesterday; it fixed bug 231282, at
> least for Thunderbird.

This also is fixed for Seamonkey.


I'm moving this bug to Core.  Outstanding features still unimplemented are:
  View | Source
  View | Character Encoding
  View | Headers, Message Body As, Display Attachment Inline
  File | Save As
  Message | Copy

Thanks again for all the effort, David!
Comment 45 Mike Cowperthwaite 2005-12-12 09:50:28 PST
*** Bug 224967 has been marked as a duplicate of this bug. ***
Comment 46 Worcester12345 2005-12-28 07:43:56 PST
Requesting a block on 2.0 as attachments should all be working properly in a product of this age.
Comment 47 Mike Cowperthwaite 2006-01-14 09:03:12 PST
*** Bug 323319 has been marked as a duplicate of this bug. ***
Comment 48 David :Bienvenu 2006-01-26 11:16:23 PST
Comment on attachment 200351 [details] [diff] [review]
support reply/forward (as attachment and inline) for message/rfc822 attachments 

would be nice for 2.0
Comment 49 Scott MacGregor 2006-01-26 13:17:30 PST
Comment on attachment 201005 [details] [diff] [review]
front end part

hopefully these patches reflect all the changes we (well you) made on the trunk for this stuff :)
Comment 50 Mike Cowperthwaite 2006-02-07 12:15:37 PST
*** Bug 268453 has been marked as a duplicate of this bug. ***
Comment 51 Jack Eidsness 2006-03-11 17:20:45 PST
In TB 3.0a1 20060311 ("trunk"), I was just able to forward a forwarded message :)
The "fix" seems to be attached to some other bug, but I thought I'd note it here because the bug I filed for that issue, specifically, was marked as a duplicate of this bug.
Comment 52 Lance E Sloan 2006-03-30 06:08:58 PST
When I attempt to use the reply or forward functions on an open attachment (usually an attached message that's part of a digest), it doesn't work, as others have reported.  I haven't noticed anybody mention the error message associated with this problem that shows up in the Javascript console.  It is:

Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIMessenger.msgHdrFromURI]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/mailCommands.js :: ComposeMessage :: line 207"  data: no]
Source File: chrome://messenger/content/mailCommands.js
Line: 207
Comment 53 Henrik Skupin (:whimboo) 2006-05-12 01:11:02 PDT
David, there are still some major issues left. I've currently checked replying to an attached message with version 2 alpha 1 (20060511) and noticed following issues:

* The originally subject is not filled in correctly. I only have "Re: "
* The "To" field is empty - no recipient is filled in (perhaps the same when using Reply-All to answer a group of recipients)
* Default identity is used instead of selecting the my other identity where the original message was sent to
* Due to the missing sender information a wrong introduction is added to the message body ("meinte am 20:59:"). There the senders name is missing and the date is also totally wrong.

It seems that most of the fields aren't initialized correctly.

To comment 52: You have to use a nightly build to check this function. By using the 1.5 release I also get this javascript exception.
Comment 54 Mike Cowperthwaite 2006-05-16 10:18:33 PDT
(In reply to comment #53)
> * The originally subject is not filled in correctly. I only have "Re: "
> * The "To" field is empty - no recipient is filled in (perhaps the same when
>   using Reply-All to answer a group of recipients)

Do you see these symptoms for *all* messages, or are they specific to certain messages with (e.g.) MIME-encoded headers?  See bug 314351.


> * Default identity is used instead of selecting the my other identity where
>   the original message was sent to

Please open a separate bug for this item.


> * Due to the missing sender information a wrong introduction is added to the
> message body ("meinte am 20:59:"). There the senders name is missing and the
> date is also totally wrong.

This might also warrant a separate bug, and a sample message would be useful.



> To comment 52: You have to use a nightly build to check this function. By
> using the 1.5 release I also get this javascript exception.

Right: that was bug 231282, fixed only on the trunk.  In fact, you can't reply to an attached message unless you're using the trunk.
Comment 55 Worcester12345 2006-05-17 10:35:45 PDT
I go to forward a message, and the body is now blank. There isn't even an attachment. 
Comment 56 Mike Cowperthwaite 2006-05-19 13:44:18 PDT
(In reply to comment #41)
>  - Print Preview and Print are working, except they show message source rather
> than as-displayed, including showing binary attachments in all their BASE64
> glory.

I've opened bug 338586 about this problem, which is Core.
Comment 57 Matthias Wallner 2006-07-12 12:26:44 PDT
*** Bug 344115 has been marked as a duplicate of this bug. ***
Comment 58 mozilla.org 2006-09-09 22:12:37 PDT
I think I am still seeing something related to this.  I have attached messages coming in as a .msg file.  when I try to open it, I get a blank message window.  With 1.5 I can't save the message either, but with 2.0 latest nightly, it creates a blank file (one step more than 1.5 does).  The crazy thing is that I export a message to a .eml file then rename it to .msg and send it to myself as an attachment. . .same blank window happens.  It should just open the file like a normal email (yes, it is rfc822) or at least prompt to save if it doesn't know what to do with it. . .
Comment 59 WADA 2006-09-10 01:05:16 PDT
(In reply to comment #58)
>I have attached messages coming in as a .msg file.
File of '.msg' extention related issue (not supported yet then funny behavior) is Bug 350819 as you already know, isn't it?
(you posted Bug 350819 Comment #6 at 2006-09-09 21:26 PDT)
Comment 60 mozilla.org 2006-09-10 14:12:24 PDT
You are correct, I posted that one as well.  It seems to be related in some ways to both bugs it seems, but probably more directly to the other.  These .msg files I am talking about are really rfc822 messages so they should show inline too.  Anyway, was trying to find the correct related bugs
Comment 61 Magnus Melin 2006-11-02 11:55:21 PST
*** Bug 357576 has been marked as a duplicate of this bug. ***
Comment 62 Mike Cowperthwaite 2006-11-05 09:02:24 PST
*** Bug 359531 has been marked as a duplicate of this bug. ***
Comment 63 Aleksandar Milivojevic 2006-11-05 11:11:26 PST
When viewing a message that has message/rfc822 attachments in 3-pane window, the message/rfc822 attachments are usually displayed inline.  It would be very useful feature if each inline displayed attachment had links with basic functionality added to it (replay/replay all/forward/print/save as).  For example, as the last line in the headers display:

=====
From:
To:
Subject:
Date:
reply | reply all | forward | print | save as

Here comes the attached message body
=====

When reading mail list digest, I don't see a need to force user to open message/rfc822 attachment to be able to reply to it.  In case of large digests, hunting to find right attachment to open (in order to be able to reply to it) can be hard.
Comment 64 Mike Cowperthwaite 2006-11-13 10:33:41 PST
*** Bug 360497 has been marked as a duplicate of this bug. ***
Comment 65 Mike Cowperthwaite 2006-11-26 09:34:08 PST
*** Bug 361882 has been marked as a duplicate of this bug. ***
Comment 66 Magnus Melin 2007-03-23 12:37:05 PDT
*** Bug 375079 has been marked as a duplicate of this bug. ***
Comment 67 Magnus Melin 2007-03-27 09:12:02 PDT
*** Bug 375478 has been marked as a duplicate of this bug. ***
Comment 68 Magnus Melin 2007-04-09 04:55:18 PDT
*** Bug 376872 has been marked as a duplicate of this bug. ***
Comment 69 Hendrik Maryns 2007-04-25 03:44:52 PDT
This is still not entirely resolved in 2.0.  I am now able to reply, forward and edit as new, but copying or moving the message to a mail folder does not work, although the menu is available (Message -> Move/Copy).
Comment 70 mozilla.org 2007-04-25 20:51:38 PDT
Would be nice to at least be able to copy (move should be possilbe too). . .I  know I used to use this with OE years ago. . .
Comment 71 Rick Yorgason 2007-06-06 00:32:07 PDT
*** Bug 383435 has been marked as a duplicate of this bug. ***
Comment 72 Magnus Melin 2007-07-14 13:27:39 PDT
*** Bug 388010 has been marked as a duplicate of this bug. ***
Comment 73 rsx11m 2007-10-03 09:57:55 PDT
When double-clicking on an .eml attachment, the forwarded message comes up in a separate message window. Account settings are compose and send as HTML, message body displayed as original HTML. Forwarding the attached message from that window causes the following encoding errors:

(1) If the message itself has an attachment, it shows up in the attachment pane of that window. When forwarding this message directly from an IMAP folder, and the message's attachment was not previously downloaded, the message's attachment is not included. The MIME headers in the forwarded message are correct, but the corresponding MIME part contains only the string "This body part will be downloaded on demand" regardless of the encoding. This is the case for both forwarding inline or as attachment from an IMAP folder.

(2) If the forwarded message is multipart/related, contains text/html with embedded images, and is forwarded inline, the compose window indicates a broken image. When sent, the image is not displayed by the receiving e-mail client. Examining the message source shows (a) a link only if the message was forwarded from an IMAP folder; or, (b) if forwarded from a local folder, the complete forwarded message/rfc822 attachment as a second part (not displayed since the top-level MIME Content-Type is multipart/related, no attachment is indicated). The format in case (b) is similar as if the .eml attached message was forwarded as attachment (in which case the top-level type would be multipart/mixed and therefore displayed correctly). Also, the "cid:" identifiers are not matching between the main message part and the embedded image in the message/rfc822 attachment.

Wrong image link for case (2a):
 <img moz-do-not-send="true" src="imap://..."  alt="">

Wrong message structure in case (2b):
> multipart/related;
>> text/html;
>>> [added text]
>>> [headers of forwarded message]
>>> [text of forwarded message]
>>> [image src="cid:part1.x"]
>> message/rfc822;
>>> multipart/related;
>>>> text/html;
>>>>> [text of forwarded message]
>>>>> [image src="cid:part1.y"]
>>>> image/{png,gif,jpeg};
>>>>> [image in base64] Content-ID <part1.y>

See http://forums.mozillazine.org/viewtopic.php?t=589399 for the corresponding discussion in the MZ forum. Verified in current Thunderbird 2.0.0.6 and SeaMonkey 1.1.4 releases (WinXP/Linux).
Comment 74 rsx11m 2008-04-24 06:40:25 PDT
Part (1) of comment #73 is similar to bug 392545, where the issue was seen in direct attachments, thus it may not be caused by an attached message.

Part (2) of comment #73 is covered by bug 334166.
Comment 75 Magnus Melin 2008-06-30 08:07:09 PDT
*** Bug 441427 has been marked as a duplicate of this bug. ***
Comment 76 rsx11m 2008-08-15 21:36:25 PDT
*** Bug 450561 has been marked as a duplicate of this bug. ***
Comment 77 Andrey G. Sergeev 2008-08-24 04:22:43 PDT
CC added.
Comment 78 Joe Sabash [:JoeS1] 2008-12-06 12:39:18 PST
*** Bug 468226 has been marked as a duplicate of this bug. ***
Comment 79 Magnus Melin 2009-01-20 09:13:05 PST
Wouldn't block for this; blocking‑thunderbird3-
Comment 80 Maketsi 2009-03-04 23:05:53 PST
That 'View message source' feature really needs to be done! 
For example abuse departments are using thunderbird, and they are constantly receiving rfc822 attached spam mails, from which they need to see full headers.
Comment 81 rsx11m 2009-03-26 06:20:08 PDT
*** Bug 477566 has been marked as a duplicate of this bug. ***
Comment 82 rsx11m 2009-04-05 06:52:26 PDT
Tsk, I don't see how bug 144276, bug 324774, and bug 369302 relate to the issue here. They are on general problems with forwarding message and breaking their encoding, not necessarily just from an attached-message window. Did you mean to establish a dependency with bug 307023 for those?
Comment 83 Magnus Melin 2009-07-26 15:00:11 PDT
View source is now enabled and works fine in thunderbird. (Don't know what changed.) Disabled in seamonkey though.
Comment 84 Joe Sabash [:JoeS1] 2009-07-26 15:17:33 PDT
(In reply to comment #83)
> View source is now enabled and works fine in thunderbird. (Don't know what
> changed.) Disabled in seamonkey though.

Nice, this will help with eml's posted in bugzilla.
A little scary though that this functionality has suddenly appeared.
I seem to remember that this would be tough to implement.
Comment 85 Mike Cowperthwaite 2009-07-27 14:18:02 PDT
View Source does work nicely -- for an opened .EML file (bug 241213).

For an *attached* email, which is this bug, the View Source does open a source window, but it displays an HTML-source representation of the message (body only).
Comment 86 Joe Sabash [:JoeS1] 2010-04-09 15:01:31 PDT
This automagically started working a while back.
I can see the source for the attached part. (I'll test with a bigger selection of eml's
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4pre) Gecko/20100408 Lanikai/3.1b2pre ID:20100408151251

BTW, that's with "view attachment inline" and also just opening the attachment itself with "!viewing...inline"
Comment 87 Thomas D. (currently busy elsewhere; needinfo?me) 2012-11-05 15:20:16 PST
Assigned to: David :Bienvenu - does that still apply?
Comment 88 Magnus Melin 2012-11-05 22:44:52 PST
Actually, i think we're done here. View source was the last piece, and that works fine now, even for attached .eml files like in comment 85.
Comment 89 Roger Lynn 2013-10-30 05:44:08 PDT
Is there a separate Seamonkey version of this bug? In Seamonkey 2.21 on Win7 none of the reply, forward or show source commands seem to work for a message/rfc822 attachment to a Mailman mailing list digest which has been opened by double clicking on it. Right clicking on the attachment in the parent message and choosing 'View Source' does work.

Note You need to log in before you can comment on or make changes to this bug.