Closed Bug 203570 Opened 21 years ago Closed 14 years ago

[message/rfc822] opening a fwd local message has original messages's attachments

Categories

(MailNews Core :: Attachments, defect)

Product:
MailNews Core
Component:
Attachments
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sspitzer, Assigned: Bienvenu)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: fixed1.8.1)

Attachments

(5 files, 1 obsolete file)

Screen shot of test case in attachment 145242
112.93 KB, image/png
Details
proposed fix
1.00 KB, patch
mscott
: superreview+
mscott
: approval1.8.0.2-
mscott
: approval1.8.1+
Details | Diff | Splinter Review
Mail folder file of mails with "nested message/rfc822 attachment" and "a file attachment"
77.55 KB, text/plain
Details
Mail to reproduce this bug
27.00 KB, application/octet-stream
Details
2nd Mail to reproduce this bug
71.60 KB, application/octet-stream
Details 
spun off from bug #203261

opening a fwd local message has original messages's attachments

this was revealed by the fix for bug #143565 (and bug #203261)

see a possibly related news issue, bug #203524

to reproduce, fwd a message.
when that message arrives in your pop account, double click on the attachment
you get the stand alone msg window, but it will have the attachments from the
original message, instead of from itsself.

note, this works for imap.
Some additional comments (from testing with 1.4b-0516).

The cross-ownership of attached items goes both ways: the "outer" (containing) 
mail can appear to own the attachments of its contained mail; and the "inner" 
(contained) mail can appear to have all the attachments of its parent, when it 
is opened into its own message window.

If the only attachment to the "outer" mail is (plain, no-attachment) "inner" 
mail, then the inner mail is shown with itself as an attachment.

Symptom occurs whether "outer" mail is HTML or plain; if the "outer" mail is 
HTML and has embedded items (such as images), those items show as attachments 
when the "inner" mail is opened in its own window.

If the "inner" mail contains misc. attachments (multipart/mixed), those 
attachments are displayed in the "outer" mail's attachment window.

But if the "inner" mail is HTML with embedded items or a plain-text alternate 
(multipart/related or multipart/alternative), those items do not show as 
attachments to the "outer" mail.

See also: bug 206278; possibly also bug 200380.
No longer blocks: 209899
Depends on: 209899
No longer depends on: 209899
*** Bug 209899 has been marked as a duplicate of this bug. ***
Please note that the duplicate has quite a bit of information that applies both 
to this bug and to the related bug 206278.
Both bug 206278 and bug 209899 Component is 'Attachments';
and not 'Mail Window Front End' like the current one...

xref bug 35587.
Agreed:

this bug is about seeing the parent's attachments,
which should not be shown;

bug 35587 is about seeing the children's attachments,
which are not separated from the current message's attachments.
Attachment of message/rfc822 is also a mail and original mail's message/rfc822
attachment is properly extracted.
On displaying this message/rfc822 attachment, message body text displaying uses
this attacehed message/rfc822 properly(probably passed as temporary ".eml" file.)
However attachment displaying thinks processing mail is the original mail in
mail box - top most mail in message/rfc822 nesting.

In message/rfc822 attachment display window, message/rfc822 part should be
treated as a whole mail in both body text displaying and attachment displaying.

In addition, "View Message Source" was grayed out in message/rfc822 attachment
display window.
This also should be activated.

Can Mozilla treat the passed temporary ".eml" file as a mail in other than mail
body displaying?
This temporary ".eml" file does not contain "From -" line, mail separator in
Unix Mbox file, and is not a real mail in Mozilla Mail&News, only a temporary file.
Bug 140979 was for invalid "View/Message Source" problem and closed as DUPE of
Bug 77337 and Bug 77337 was already fixed.
In Bug 140979, reporter said "View/Message Source" worked although displayed
result was not valid.
When "View/Message Source" was disabled?
Due to crash problem?
Bug 201881 was already opened for "View/Message Source". Sorry for spam. 

Bug 20188 was who disabled "View/Message Source".  
Bug for disabled "View/Message Source" was Bug 204350.

If direct handling of message/rfc822 attachment is too difficult, adding "save
message/rfc822 attachment as a mail in mail folder" function can be a
short/middle term workaround.
This will reduce user's workload and resolves many problems in replying,
forwarding, extracting attachments and viewing source of message/rfc822
attachment, because Mozilla Mail&News can do everything  on real mail.
If this is done internaly and automaticaly in handling message/rfc822
attachment, it's better.

By the way, please add "message/rfc822"(at least "rfc822") in summary for ease
of understanding and search (I have no previledges for it).
re: comment 10:  Bug 201881 (not 20188) hasn't had a patch checked in against 
it, as far as I can tell; View|Source was probably disabled in the fix for 
bug 143565, the original implemenation of opening an RFC822 attachment into a 
message window.

re: comment 8:  The problem described in bug 140979 doesn't manifest for me, so 
I assume it was properly marked as a dupe of the fixed bug.
Summary: opening a fwd local message has original messages's attachments → [message/rfc822] opening a fwd local message has original messages's attachments
(In reply to comment #11)

> bug 143565, the original implemenation of opening an RFC822 attachment into a
message window.

Thanks Mike. I could understood message/rfc822(*.eml) support status now by you.

Since bug 143565 was implemented as an enhancement for ".eml" handling, I guess
treatment of passed temporary file(".eml") as a "mail" seems to have no problem
any where in message/rfc822 attachment display.
And I guess cause of improper display of attacments is invalid pointer or
mis-pointing to the "mail" which attachment display logic sees, original mail in
a mail box instead of passed temparary ".eml" file.
Can this pointer to the "mail" be easily be changed from original mail to passed
temporary ".eml" file?
In
http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/messageWindow.js#275
variables for displaying mail are set os follows ;
> messageUri = window.arguments[0];
> gCurrentFolderUri = window.arguments[1];
> originalView = window.arguments[2];

I guess current-displayed mail(=whole mail) is passed as arguments[0] and
temporary ".eml" is passed as arguments[2] on opening mail window for
message/rfc822 attachment, and message body text display logic uses
originalView(argument[2]) but attachment display logic uses
messageUri(argument[0]) in the opened mail window.

I think opener of the mail window should pass the temporary ".eml"(argument[2])
as messageUri(argument[0]) on mail window open if  message/rfc822 attachment.
(gCurrentFolderUri(argument[1]) should be Null, probably)

I guess opening new mail window for attachment is also done as 
MsgOpenNewWindowForMessage in mailWindowOverlay.js does.
http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/mailWindowOverlay.js#1237

> window.openDialog( "chrome://messenger/content/messageWindow.xul", "_blank",
"all,chrome,dialog=no,status,toolbar", messageUri, folderUri, gDBView );

If this window.openDialog is requested for message/rfc822 attachment,  I think
parameters for the mail window should be "messageUri, folderUri, messageUri"
instead of "messageUri, folderUri, gDBView".
(I assume messageUri is the choosed attachment and gDBView is the mail itself
when this is used on open request of message/rfc822 attachment) 
This mail folder file contains following four mails ; 
 (1) Subject = HTML Mail 
     An HTML mail with an attachment of a jpeg file
 (2) Subject = [Fwd: HTML Mail]
     An forwarded mail. Mail (1) is attached as message/rfc822 attachment.
 (3) Subject = [Fwd: [Fwd: HTML Mail]]
     Nested forwarded mail. Mail (2) is attached as message/rfc822 attachment.
 (4) Subject = [Fwd: [Fwd: [Fwd: HTML Mail]]] 
     Nested forwarded mail. Mail (3) is attached as message/rfc822 attachment.

Save this file in your mail directry as a file (for example, "TEST-MAILS") and
restart Mozilla ot Thunderbird.
You will see folder of "TEST-MAILS" and above four mails in it.
Left screen is message/rfc822 attachment of mail (4) of preview pame(message
pane).
In attachment: box at preview pane, only "[Fwd: [Fwd: HTML Mail]]"(mail (3)) is
displayed.
If this attachment(mail (3)) is displayed, mail body display is proper but all
attachments (even in nested message/rfc822 attachemnts) are displayed.

Right screen is attachment named [Fwd: HTML Mail], second one in attachment:
box of left screen, which is same as mail (2).
Mail body display is proper but attachment: box is same as left screen shot -
all attachments (even in nested message/rfc822 attachemnts) are displayed.

These result indicates 2 problme in message/rfc822 attachment display ;
 (1) Whole mail ( mail (4) in above test ) is used in attachment handling.
 (2) Nesting of message/rfc822 attachment are not processed properly
     in stand-alone message display window for message/rfc822 attachment.

Problem (1) and (2) maybe are different problem.
Attachment number for screen shot became invalid due to my mis-operation.
Sorry for my mistake.

Screen shot is attachment 145277 [details].


Additional information.
Above screen shots are taken with 2004033108-trunk/Win-2K(SP4).
Description change of summarized problems in Comment #16.

[No change]
(1) Whole mail ( mail (4) in above test ) is used in attachment handling.
    This bug.
[Description change]
(2-A) message/rfc822 attachment is displayed in format of
      - "Message body as HTML"(I can not say which of Original or Simple),
      - "Display Attachments Inline",
(2-B) These View menu options are killed.
      - Options can be changed but display format will not be changed.
      Probably Bug 204350.
     "Attached email message window glitches(forward,reply,view source disabled)"
[New]
(3) If attached message/rfc822 is HTML mail,
    included images(multipart/related part) is not displayed.
*** Bug 260892 has been marked as a duplicate of this bug. ***
*** Bug 261047 has been marked as a duplicate of this bug. ***
Description change of summarized problems in Comment #19.

[No change]
(1) Whole mail ( mail (4) in above test ) is used in attachment handling.
    This bug.

[Description change - reported in other bug?]
(2-A) message/rfc822 attachment is displayed in format of
      - "Message body as HTML"(I can not say which of Original or Simple),
      - "Display Attachments Inline"
      Same as Bug 206278? (Mail, Bug 203524 for News)
      Or same as Bug 204350?

[No change]
(2-B) These View menu options are killed.
      - Options can be changed but display format will not be changed.
      Probably Bug 204350.

[Description change - reported in other bug]
(3) If attached message/rfc822 is HTML mail,
    included images(multipart/related part) is not displayed.
    This is probably same as Bug 206278 (Mail) or Bug 203524 (News)
Product: Browser → Seamonkey
Component: MailNews: Main Mail Window → MailNews: Attachments
Product: Mozilla Application Suite → Core
QA Contact: esther
*** Bug 273782 has been marked as a duplicate of this bug. ***
No longer blocks: 241267
*** Bug 241267 has been marked as a duplicate of this bug. ***
Change "Assigned to:" to David, since original assignee is "not reading bugmail".
David, could you comment on this problem.
Assignee: sspitzer → bienvenu
Severity: normal → major
No longer blocks: 279650
Depends on: 279650
Blocks: 279650
No longer depends on: 279650
Blocks: 269826
No longer depends on: 269826
*** Bug 278048 has been marked as a duplicate of this bug. ***
*** Bug 299609 has been marked as a duplicate of this bug. ***
*** Bug 302409 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
Attached patch proposed fix — — Splinter Review 
this fixes two problems with local msgs:

1. Opening a forwarded message with inline image attachments displayed broken
images.
2. The forwarded message shows up as an attachment of itself, as described in
this bug.

The cause of these problems was that the base url was ending up just being the
mailbox, and not the mail message. Perhaps this fix will expose other problems,
but we might as well find out now. Things seem to be working quite a bit better
for me.
Attachment #199818 - Flags: superreview?(mscott)
Attachment #199818 - Flags: superreview?(mscott) → superreview+
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Reopen because problem(described in summary) still occurs on "Thunderbird version 1.6a1 (20051027)" (latest-trunk, 10/27 build, Win-2K).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
No longer blocks: 279650
(Additonal comment to comment #30)
Problem of this bug is surely resolved when Seamonkey latest-trunk 2005102717/Win-2K, although "Display Attachment Inline" is still always applied on attachments display at opened window...
What's wrong when Thunderbird latest-trunk?
since I checked the fix in on 10/27, I'd be surprised if the 10/27 build has the fix in it. Can you try today's build, and re-open if you still see the problem in today's build? thx.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
I verify this is fixed with TB 1.6a1-1028, Win2K.  I'll try to check against a Seamonkey build over the weekend.

Note that the symptom from bug 35587 is still visible, but not if "Display Attachments Inline" is turned off.  Also note that changing Display Attachments Inline in the attachment's own message window is ineffective, but that's part of bug 204350 or its TB equivalant.

However, the symptom of bug 206278 does not manifest.  David, might that have been fixed by this patch, or the patch of these related bugs?
Status: RESOLVED → VERIFIED
yes, bug 206278 was one of the things I fixed. I'll mark it fixed.
(In reply to comment #32)
> I'd be surprised if the 10/27 build has the fix in it.
Me too! :-)
I knew this bug was fixed, and saw this bug again, and found last comment 29 on 10/17, then I'm convinced this bug was fixed around 10/17... 
I should have opened "View Bug Activity".

I'm sorry to be reopening after verifying, but I didn't test sufficiently; this bug's fix is incomplete.  The fixed version does properly hide the parent message, but it does not hide the parent's other attachments.

To reproduce:
1) Select a message, forward as attachment
2 [review]) in the compose window, attach some file from disk, or another message
3) Send to yourself
4) On receipt, select the message, double-click on the forwarded message.

Actual results:
Message window shows the attached file in its attachment bucket

Expected results:
No attachments shown

This is the obverse of bug 35587, but I don't think David's argument against fixing that bug applies to this bug; there is no convenience offered in showing the parent's attachments.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Replacement of previous test case(attachment 145243 [details]).
This is for newly found problem of comment #36 by Mike.
Attachment #145242 - Attachment is obsolete: true
Note for my test case.
File name of file attachment is "attachment.pdf" but is not a real pdf file(HTML file). This is done to force Base64 attachment. Please don't open it with Adobe Reader, please. 
*** Bug 320571 has been marked as a duplicate of this bug. ***
Flags: blocking-thunderbird2?
Comment on attachment 199818 [details] [diff] [review]
proposed fix

It'd be nice to get this fix on the branch at the next feasible juncture -- see bug 320571.
Attachment #199818 - Flags: approval1.8.1?
Attachment #199818 - Flags: approval1.8.0.2?
Attachment #199818 - Flags: approval1.8.0.1?
Attachment #199818 - Flags: approval1.8.1?
Attachment #199818 - Flags: approval1.8.1+
Attachment #199818 - Flags: approval1.8.0.1?
Flags: blocking-thunderbird2? → blocking-thunderbird2+
or at least, fixed to the extent that the trunk is.
Keywords: fixed1.8.1
*** Bug 320571 has been marked as a duplicate of this bug. ***
*** Bug 325244 has been marked as a duplicate of this bug. ***
Comment on attachment 199818 [details] [diff] [review]
proposed fix

i don't believe we should take this for the security branch. It's not a regression over 1.0.x and it's not security related. It has already been checked in for Thunderbird 2.0.
Attachment #199818 - Flags: approval1.8.0.2? → approval1.8.0.2-
*** Bug 350024 has been marked as a duplicate of this bug. ***
*** Bug 336650 has been marked as a duplicate of this bug. ***
I haven't digested all the details of Bug 203570, but as I reported in my Bug 343121 filing, the problem of nested attachments as I experienced it was present in SeaMonkey 1.02, but not in Mozilla 1.7.12.  So if what I experienced is the same problem, with the same cause, as 203570, it's curious that it wasn't there in Mozilla 1.7.12, but reappears in SeaMonkey 1.02.  Bug 203570 was opened on 2003-04-27, which predates the migration from the Mozilla Suite to SeaMonkey, and that suggests that something may have been changing back and forth over this time and through these releases.
*** Bug 343121 has been marked as a duplicate of this bug. ***
*** Bug 353384 has been marked as a duplicate of this bug. ***
According to the release announcement of 2.0 alpha 1 (see http://weblogs.mozillazine.org/rumblingedge/archives/2006/05/2-0alpha1.html ), this bug should be fixed.  However, I'm running 2.0 beta 1 here and I'm still experiencing the problem describe here.

It would really be nice if this bug could be fixed until the final release of TB 2.0.  If you need more information about how to reproduce this bug, feel free to contact me!

Thanks,  Chris
Comment 50 is correct -- this fix has regressed.  I see the symptom 
in TB 2b1-0105 and 3a1-1230.
I think I tested something incorrectly when I looked at comment 50 -- I don't see a regression of the fix in current builds.  However, the symptom described at comment 36 is still present, which is why this bug was reopened.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → FIXED
Note, that I had to truncate the PDF-attachment because of the upload-limit of this bugzilla installation.  Therefore, the PDF-attachment is invalid.  However, this mail can still be used to demonstrate this bug.
(In reply to comment #53)
> I think I tested something incorrectly when I looked at comment 50 -- I don't
> see a regression of the fix in current builds. 

Hi Mike!  For clarification, I've attached an example e-mail which demonstrates the bug I'm talking about.  This bug still is present in 2.0b1:
- just place the specified file on an IMAP server
- and access it via TB
- when opening the inner e-mail (the attachment of the outer e-mail), the inner 
  e-mail will not display the PDF-attachment

However, when loading the message via "File > Open Saved Message...", the PDF attachment is displayed correctly.


Thanks,

Chris
Oh -- I see I marked this bug Fixed, again, on Jan 10; that was an error.  Reopening.

(In reply to comment #55)
> Hi Mike!  For clarification, I've attached an example e-mail which
> demonstrates the bug I'm talking about.  This bug still is present in 2.0b1:
> - just place the specified file on an IMAP server
> - and access it via TB
> - when opening the inner e-mail (the attachment of the outer e-mail), the
>   inner e-mail will not display the PDF-attachment
> 
> However, when loading the message via "File > Open Saved Message...", the PDF
> attachment is displayed correctly.

I don't know what you're talking about.  I can't even tell which of the statements above you consider to be a problem.  Further, the test message you supply is not the sort of message that's under consideration in this bug; rather, it's the sort of message considered by bug 35587.  The behavior in that case is affected by the setting of   View | Display Attachments Inline.

If the problem you're discussing is IMAP-specific, then it's not this bug.  I don't see a difference in behavior with that test message on my IMAP server than when it's in a local folder.

Note that when viewing a message using   File | Open   it's not possible to open an attached message into its own window; this is bug 351064.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #56)
> I don't know what you're talking about.  I can't even tell which of the
> statements above you consider to be a problem.  Further, the test message you
> supply is not the sort of message that's under consideration in this bug;
> rather, it's the sort of message considered by bug 35587.  The behavior in
> that case is affected by the setting of   View | Display Attachments Inline.

I've just uploaded another email message which demonstrates my problem more clearly (see "2nd Mail to reproduce this bug" attachment above).  Thunderbirds behaviour with this messsage is the following:

case a: message is in an IMAP folder:

 - I click on the message in the folder list to open it
 - TB displays the message body and lists the attachments, in this case
     - "attachment2 [details] [diff] [review].pdf"
     - "Test-Mail with attachment1 [details] [diff] [review] attached"
   (this is correct)
 - when I double-click on the "Test-Mail with attachment1 [details] [diff] [review] attached" attachment
   (that's the forwarded email), TB opens a new window, displays this message's
   body and lists the attachments; this time, I see:
     - "attachment2 [details] [diff] [review].pdf"

    => that's the BUG: the inner message had "attachment1 [details] [diff] [review].pdf" attached
       (attachment2 [details] [diff] [review].pdf was attached to the outer message!)

    => That's why I assume that this is the bug 203570: "opening a fwd local 
       message has original messages's attachments"

    Note, that the behaviour I see with this message is invariant with the 
    setting of the "Display Attachments Inline" flag.

case b: place message in a local folder (non-IMAP):

 - TB displays all attachments correctly
 - this time, the "Display Attachments Inline" flag works as supposed

> If the problem you're discussing is IMAP-specific, then it's not this bug.  I
> don't see a difference in behavior with that test message on my IMAP server
> than when it's in a local folder.

I do see a difference.  I've tested with TB 1.5.0.9 and TB 2.0b1.  Is there a newer build which I can use to test?

> Note that when viewing a message using   File | Open   it's not possible to
> open an attached message into its own window; this is bug 351064.

Well, for me, opening the message using File | Open work's :-)  Maybe bug 351064 just covers HTML-messages?  (I've used plain text-messages for this test.)


Thanks for your help!

Chris

(In reply to comment #58)
Note that Bugzilla mis-interprets the filenames I mentioned in my last comment...  We Bugzilla displays 
   "attach-ment2 [details].pdf"   (without the dash)
I wrote
   "attach-ment2.pdf"   (without the dash)

:-)
Blocks: 370090
Since this bug has been reopened, should I assume that this fix is also not on the branch? If so, can you please remove the fixed1.8.1 keyword?
(In reply to comment #60)
> should I assume that this fix is also not on
> the branch? If so, can you please remove the fixed1.8.1 keyword?

No: a modified version of the patch was included in (v1.78 and)
"1.77.4.1	bienvenu%nventure.com	2006-01-27 14:31".
This bug should be either closed or renamed to reflect that it is IMAP-only:

According to comment #58, case b, there is no bug any more (finally!!!) when the main msg containing the forwarded-msg.eml attachment is in a *local* folder (non-IMAP). Current summary of this bug explicitly refers to "local msg" (even though wording is not very clear). The bug is fixed for local msgs, as I hereby confirm: the forwarded-msg.eml attachment no longer pretends to have the attachments of the main msg. For IMAP, I don't know. (However, bug 35587 still exists: if "show attachments inline" is activated, attachments inside of forwarded-msg.eml are displayed together with main-msg attachments.)

We're using Thunderbird 2.0.0.9 with IMAP and I can confirm that this bug still exists for IMAP.  When I copy the message from an IMAP folder to a Local folder and then view the Local folder version of the message, I see the attachments properly.

Is there an IMAP version of this bug?  If not, when might the IMAP part be addressed?

Thanks.

Doug
Flags: blocking-thunderbird3?
No longer blocks: 320571
QA Contact: attachments
(In reply to comment #63)
> Is there an IMAP version of this bug?  If not, when might the IMAP part be
> addressed?

The behavior described in comment 36 still manifests in TB 3pre1-0419, and doubtless later versions; I just tried with a message sent to a POP account, and also copied it to an IMAP account.  I did not try sending to an IMAP account and then copying to a local folder, but I see no reason to expect different behavior; this is a MIME decoding issue, not a storage issue.
URL: see comment 36
Product: Core → MailNews Core
Wanted, but not blocking.
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
(In reply to comment #36)
> I'm sorry to be reopening after verifying, but I didn't test sufficiently; this
> bug's fix is incomplete.  The fixed version does properly hide the parent
> message, but it does not hide the parent's other attachments.

I've spin off Bug 559532 to track that so we can properly go forward.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 14 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: