From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 BuildID: 2002041711 In Moz1.0RC1, when attaching a Mail message to a new one, the headers are shown. But the headers shown are not only the attachment headers, but all or different ones. In the 3-pane window, all headers are shown as attachment headers; if the mail is shown in an extra window, ONLY the new mail headers are shown. This is only a viewing bug. Reproducible: Always Steps to Reproduce: 1. Pick a mail you got. 2. Forward it to you (as attachment). 3. Look at the new mail. Actual Results: In the 3-pane-layout, it will show your text, a horizontal ruler, and below that the original mails "From" and "Date" lines. Below, in a gray box, the "To:" and "Received:" lines. This grey box shows ALL received lines from the mail. Expected Results: Should only show the Header lines from the attachment. If you show the mail in its own window, it will show different lines in that grey box with the headers of the attached mail.

I see this bug, in the standalone msg window. timeless pointed me to it, he also saw it. confirming.

this bug is not minor.

I can't see the duplicate headers problem in more current versions of Mozilla. I am using Moz1.2a with or without Enigmail 0.65.4.0 and the problem is not there. So this is a WORKSFORME in current browsers.

Bug exists in build 2002-11-12-11 (Windows 2000) Please change OS to all. I see the same sender headers for email attachments. (drag&drop emails to the attachmentbox when creating the mail) Only the "subject", "from", "date" and the "to" headers are correct. All other headers are from the sended mail. The first and last wrong header ist the "X-UIDL" header.

It seems that this behavior isn't new. I found a bug where it is was reported too but I didn't find an existing bug for this. bug 73413 comment 53 (also see coments 76 and 83)

Changed OS to all.

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

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

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

OK; I reported bug 183005 which has just been marked as a dup of this bug. I'm finding the original report here a little hard to follow, but I'm not certain its the same bug. The report here states that the problem does not show up in an extra mail window but only in the 3 pane view; my bug was definitely showing in the extra window (I did not test it in the 3 pane view).

I've seen this bug in mozilla 1.2.1 and trunk 2003012422. It occurs on messages forwarded to me. I've forwaded mails to myself, and seen this occur. If set: View->Headers->All Then bug occurs If set: View->Headers->Normal Then bug does not occur. As with Julian, I see this occur with 3-pane window and in a stand alone mail message window. Would be happy to do JS (or at a stretch gdb) debug of this, if the developers need. (Would need directions as to where to set breakpoints, what vars to monitor etc) This is a description of the forwarded message header: FOLLOWING IN LIGHT GREY: Subject: - From forwarded message From: - From forwarded message Date: - From forwarded message FOLLOWING IN DARK GREY: To: - From forwarded message <Whole of container message header> FORWARDED MESSAGE BODY

I'm using Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.3) Gecko/20030313. I didn't realize it in older versions. It shows in 3-pane and in mail-only window. It shows with all or normal headers-view. On my Win-Mozilla_1.0-Version: it shows only with all Headers. All Headers except *from*, *date* and *subject* are from the actual mail and not from the forwarded mail.

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030529] Confirming bug in v1.4rc1: with both Normal/All and 3-pane/stand-alone behaviours as in comment 11.

Addition to comment 13: In the attachment, the forwarded message actually had no "To:" line, so it doesn't display either: right. The bug is obvious to see from the 2 'X-Mozilla-Status*' lines for example. The bug can also be seen in the 'Sent' folder for messages which you forward.

This is still an issue in 1.4 final and 1.5a

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

Is this really a MIME-component bug? Looks like front-end to me. The rewritten summary for this bug is hard to read, and not much more descriptive than the original.

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

It seems that the error is in nsMimeBaseEmitter.cpp Two lists with headers are build: mHeaderArray contains the headers of the top mail mEmbeddedHeaderArray the headers of the embedded mail The headers for TO, CC, BCC, NEWSGROUPS, SUBJECT, FROM, DATE shown with the method "OutputGenericHeader", which either takes the values from the one or the other header list. All other headers are shown in "DumpRestOfHeaders", which only uses "mHeaderArray" and not "mEmbeddedHeaderArray".

I have no CVS access from here, so I could not create a real patch with patch-maker. I changed <-- cut --> for (i=0; i<mHeaderArray->Count(); i++) { headerInfoType *headerInfo = (headerInfoType *)mHeaderArray->ElementAt(i); <-- cut --> by <-- cut --> nsVoidArray *tmpHeaderArray; if (mDocHeader) tmpHeaderArray = mHeaderArray; else tmpHeaderArray = mEmbeddedHeaderArray; for (i=0; i<tmpHeaderArray->Count(); i++) { headerInfoType *headerInfo = (headerInfoType *)tmpHeaderArray->ElementAt(i); <-- cut -->

I suspect this same confusion with picking the headerInfoType pointer also causes the headers of attached email messages to be unsearchable (the attachment email headers are not part of the body of the message, nor can they be found using the normal header searches which only go through "parent" email headers). Would Mr. de Wildt or someone else who is familiar with the source like to confirm this, and maybe offer a patch also for this?

Compiling and debugging code implied not that I am familar with it. Searching for mails is a completly different kind of functionality (and also a different part of the source code). As far as I could see are the attachments not parsed, so I guess that your request is not a bug but an enhancement. Searching in the body implicits also searching in the attachments (and headers). If you think searching for headers in attachment is a necessary functionality, it would be necessary to fill a new bug with severity set to "enhancement". (Such an enhancement is no part part of this bug.)

Currently, as far as message search is concerned, the attachment message headers do not exist -- they are not a part of the main message headers, nor are they a part of the message body. Surprisingly enough, the attachment body content can be searched using normal body search. If you believe this is not due to a related bug in spite of sounding quite similar, I will open another ticket on it?

Patch based on Daniel de Wildt's suggestion in comment 20.

Comment on attachment 134475 [details] [diff] [review] Daniel's patch Seeking review and super-review.

Comment on attachment 134475 [details] [diff] [review] Daniel's patch instead of + nsVoidArray *tmpHeaderArray; + + if (mDocHeader) + tmpHeaderArray = mHeaderArray; + else + tmpHeaderArray = mEmbeddedHeaderArray; I'd say void *tmpHeaderArray = (mDocHeader) ? mHeaderArray : mEmbeddedHeaderArray;

Comment on attachment 134475 [details] [diff] [review] Daniel's patch >+ nsVoidArray *tmpHeaderArray; >+ >+ if (mDocHeader) >+ tmpHeaderArray = mHeaderArray; >+ else >+ tmpHeaderArray = mEmbeddedHeaderArray; Initialize tmpHeaderArray (what a lousy variable name) with ?: please.

Comment on attachment 134475 [details] [diff] [review] Daniel's patch The patch is correct but incomplete. The function nsMimeBaseEmitter::DumpToCC() need a similar fix, else, the recipient of the embedded message wont be displayed if the main headers does not contains any recipient fields!

I did wonder about that... btw this diff contains other cleanup.

Comment on attachment 134484 [details] [diff] [review] Fixed DumpToCC The patch is good.

Comment on attachment 134484 [details] [diff] [review] Fixed DumpToCC sr=bienvenu

Whoops, forgot to mark this fixed.

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

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

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