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

RESOLVED FIXED

Status

MailNews Core
Attachments
RESOLVED FIXED
15 years ago
4 years ago

People

(Reporter: Mike Cowperthwaite, Assigned: Bienvenu)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug, {fixed1.8.1})

Trunk
fixed1.8.1
Dependency tree / graph
Bug Flags:
blocking-thunderbird3 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

15 years ago
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

15 years ago
Hardware/OS -> All. (Seeing this on Mac build 2003-04-19-03.)   
OS: Windows 2000 → All
Hardware: PC → All
(Reporter)

Comment 2

14 years ago
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.
(Reporter)

Comment 3

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

Comment 4

14 years ago
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.
(Reporter)

Comment 5

14 years ago
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.
(Reporter)

Comment 6

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

Comment 7

14 years ago
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.
(Reporter)

Comment 8

14 years ago
Adding dependency on bug 218912 -- that bug notes that Edit As New doesn't work 
for the messagewindow containing the attachment.
Depends on: 218912

Comment 9

14 years ago
Created attachment 137257 [details]
digested mailing list reveived via email

Comment 10

14 years ago
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.
Flags: blocking1.6?

Updated

14 years ago
Flags: blocking1.6? → blocking1.6-

Comment 11

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

Comment 12

14 years ago
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
Summary: Opening attached email shows a message window with glitches → Message window for attached email has glitches (forward, reply, view source disabled)

Comment 13

14 years ago
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.
Depends on: 162646, 204612
(Reporter)

Comment 14

14 years ago
Adding dependency on bug 3901:
  "want ability to forward message/rfc822 attachments"
Depends on: 3901
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.
Blocks: 223801
Please add "message/rfc822"(at least "rfc822") in summary for ease of search.
(I have no previridges for it)

Updated

14 years ago
Summary: Message window for attached email has glitches (forward, reply, view source disabled) → (message/rfc822) Attached email message window glitches (forward, reply, view source disabled)

Comment 17

14 years ago
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...
(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.
(Reporter)

Updated

14 years ago
Depends on: 236397

Comment 19

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

Updated

14 years ago
No longer depends on: 162646
(Reporter)

Comment 20

14 years ago
*** Bug 234998 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 21

14 years ago
*** Bug 239980 has been marked as a duplicate of this bug. ***
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?
(Reporter)

Comment 23

14 years ago
See bug 241213.

Comment 24

13 years ago
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

13 years ago
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

13 years ago
(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

13 years ago
(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

13 years ago
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).
(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

13 years ago
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.
Product: Browser → Seamonkey
(Reporter)

Comment 31

13 years ago
*** Bug 190673 has been marked as a duplicate of this bug. ***
Blocks: 224967
Blocks: 279650
Blocks: 280862
No longer blocks: 280862
No longer blocks: 279650
Depends on: 279650
Depends on: 269826
Blocks: 279650
No longer depends on: 279650
Blocks: 269826
No longer depends on: 269826
Blocks: 3901
No longer depends on: 3901

Updated

13 years ago
Assignee: sspitzer → mail

Comment 32

13 years ago
(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.


FWIW - Bug 201881 Comment 8 suggests Bug 201881 be marked WONTFIX due to the
number of votes here for this bug, bug 204350.
(Reporter)

Comment 34

12 years ago
Adding dependency on bug 310264, which wants to be able to print an attached 
message.
Depends on: 310264

Comment 35

12 years ago
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.
(Assignee)

Comment 36

12 years ago
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.
Assignee: mail → bienvenu
Status: NEW → ASSIGNED
Attachment #200351 - Flags: superreview?(mscott)

Comment 37

12 years ago
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.
Attachment #200351 - Flags: superreview?(mscott) → superreview+
(Assignee)

Comment 38

12 years ago
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...
(Reporter)

Comment 39

12 years ago
*** Bug 313978 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 40

12 years ago
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...
Attachment #201005 - Flags: superreview?(mscott)
No longer blocks: 279650
(Reporter)

Comment 41

12 years ago
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.

Updated

12 years ago
Attachment #201005 - Flags: superreview?(mscott) → superreview+

Comment 42

12 years ago
(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". 
(Reporter)

Comment 43

12 years ago
Attachment 201005 [details] [diff] was checked in yesterday; it fixed bug 231282, at least for Thunderbird.
(Reporter)

Comment 44

12 years ago
(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!
Component: MailNews: Main Mail Window → MailNews: Attachments
Product: Mozilla Application Suite → Core
(Reporter)

Comment 45

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

Comment 46

12 years ago
Requesting a block on 2.0 as attachments should all be working properly in a product of this age.
Flags: blocking-aviary2?
(Reporter)

Comment 47

12 years ago
*** Bug 323319 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 48

12 years ago
Comment on attachment 200351 [details] [diff] [review]
support reply/forward (as attachment and inline) for message/rfc822 attachments 

would be nice for 2.0
Attachment #200351 - Flags: approval1.8.1?
(Assignee)

Updated

12 years ago
Attachment #201005 - Flags: approval1.8.1?

Updated

12 years ago
Attachment #200351 - Flags: approval1.8.1? → approval1.8.1+

Comment 49

12 years ago
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 :)
Attachment #201005 - Flags: approval1.8.1? → approval1.8.1+
(Assignee)

Updated

12 years ago
Keywords: fixed1.8.1
(Reporter)

Comment 50

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

Comment 51

12 years ago
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.

Updated

12 years ago
Flags: blocking1.9a1?

Comment 52

12 years ago
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
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.
(Reporter)

Comment 54

11 years ago
(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

11 years ago
I go to forward a message, and the body is now blank. There isn't even an attachment. 
(Reporter)

Comment 56

11 years ago
(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.
(Reporter)

Updated

11 years ago
Depends on: 327936

Comment 57

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

Comment 58

11 years ago
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. . .
(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

11 years ago
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

11 years ago
*** Bug 357576 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 62

11 years ago
*** Bug 359531 has been marked as a duplicate of this bug. ***
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.
(Reporter)

Comment 64

11 years ago
*** Bug 360497 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 65

11 years ago
*** Bug 361882 has been marked as a duplicate of this bug. ***
Depends on: 366482

Updated

11 years ago
Blocks: 370090

Updated

11 years ago
Duplicate of this bug: 375079

Updated

11 years ago
Duplicate of this bug: 375478

Updated

11 years ago
Flags: blocking1.9a1?
Flags: blocking1.6-

Updated

11 years ago
Duplicate of this bug: 376872

Comment 69

11 years ago
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

11 years ago
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. . .

Updated

10 years ago
Duplicate of this bug: 383435

Updated

10 years ago
Duplicate of this bug: 388010

Comment 73

10 years ago
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).

Updated

10 years ago
Flags: blocking-thunderbird3?

Updated

9 years ago
Depends on: 334166

Comment 74

9 years ago
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.
No longer blocks: 224967

Updated

9 years ago
QA Contact: esther → attachments

Updated

9 years ago
Duplicate of this bug: 441427
Product: Core → MailNews Core

Updated

9 years ago
Duplicate of this bug: 450561

Comment 77

9 years ago
CC added.

Updated

9 years ago
Duplicate of this bug: 468226

Comment 79

9 years ago
Wouldn't block for this; blocking‑thunderbird3-
Flags: blocking-thunderbird3? → blocking-thunderbird3-

Comment 80

9 years ago
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.

Updated

9 years ago
Duplicate of this bug: 477566
Depends on: 144276
Depends on: 369302
Depends on: 324774

Comment 82

9 years ago
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

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

Comment 84

8 years ago
(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.
(Reporter)

Comment 85

8 years ago
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).

Updated

8 years ago
No longer depends on: 369302

Updated

8 years ago

Updated

8 years ago
Depends on: 544359
No longer depends on: 144276, 324774
Whiteboard: [view source still needs fixing]

Comment 86

8 years ago
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"
Assigned to: David :Bienvenu - does that still apply?

Comment 88

5 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [view source still needs fixing]

Comment 89

4 years ago
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.
You need to log in before you can comment on or make changes to this bug.