204350 - (message/rfc822) Attached email message window glitches (forward, reply, view source disabled)

Status: RESOLVED FIXED

(MailNews Core :: Attachments, defect)

Description

[Mike Cowperthwaite]

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]

Hardware/OS -> All. (Seeing this on Mac build 2003-04-19-03.)   

Comment 2

[Mike Cowperthwaite]

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]

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

Comment 4

[:aceman]

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]

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]

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

Comment 7

[Luke Walling]

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]

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]

Attachment: digested mailing list reveived via email

Comment 10

[Robert Marshall]

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]

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

Comment 12

[Joe Infla]

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]

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]

Adding dependency on bug 3901:
  "want ability to forward message/rfc822 attachments"

Comment 15

[Wolfgang Rosenauer [:wolfiR]]

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:World Anti-bad-Duping Agency]

Please add "message/rfc822"(at least "rfc822") in summary for ease of search.
(I have no previridges for it)

Comment 17

[FZiegler]

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:World Anti-bad-Duping Agency]

(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]]

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

Comment 20

[Mike Cowperthwaite]

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

Comment 21

[Mike Cowperthwaite]

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

Comment 22

[WADA:World Anti-bad-Duping Agency]

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]

See bug 241213.

Comment 24

[Moritz Naumann]

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]

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.]

(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]

(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]

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:World Anti-bad-Duping Agency]

(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]

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]

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

Comment 32

[Filip Miletic]

(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)]

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]

Adding dependency on bug 310264, which wants to be able to print an attached 
message.

Comment 35

[wind li]

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]

Attachment: 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]

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]

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]

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

Comment 40

[David :Bienvenu]

Attachment: 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]

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]

(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]

Attachment 201005 [details] [diff] was checked in yesterday; it fixed bug 231282, at least for Thunderbird.

Comment 44

[Mike Cowperthwaite]

(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]

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

Comment 46

[Worcester12345]

Requesting a block on 2.0 as attachments should all be working properly in a product of this age.

Comment 47

[Mike Cowperthwaite]

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

Comment 48

[David :Bienvenu]

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]

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]

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

Comment 51

[Jack Eidsness]

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]

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][⌚️UTC+1]]

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]

(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]

I go to forward a message, and the body is now blank. There isn't even an attachment. 

Comment 56

[Mike Cowperthwaite]

(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

[u49640]

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

Comment 58

[mozilla.org]

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:World Anti-bad-Duping Agency]

(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]

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 [:mkmelin]]

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

Comment 62

[Mike Cowperthwaite]

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

Comment 63

[Aleksandar Milivojevic]

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]

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

Comment 65

[Mike Cowperthwaite]

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

Comment 69

[Hendrik Maryns]

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]

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 73

[rsx11m]

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]

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 77

[Andrey G. Sergeev]

CC added.

Comment 79

[Magnus Melin [:mkmelin]]

Wouldn't block for this; blocking‑thunderbird3-

Comment 80

[Maketsi]

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 82

[rsx11m]

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 [:mkmelin]]

View source is now enabled and works fine in thunderbird. (Don't know what changed.) Disabled in seamonkey though.

Comment 84

[Joe Sabash [:JoeS1]]

(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]

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]]

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. (:thomas8)]

Assigned to: David :Bienvenu - does that still apply?

Comment 88

[Magnus Melin [:mkmelin]]

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]

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.