Closed Bug 140532 Opened 23 years ago Closed 21 years ago

With 'Headers > All', forwarded message (non Normal) headers display/show parent (= Sent/Received) headers instead of the forwarded ones, in Mail Window (both 3-pane/stand-alone)

Categories

(MailNews Core :: MIME, defect)

x86
All
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Stefan.Helfert, Assigned: bugzilla)

References

Details

Attachments

(2 files, 2 obsolete files)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
this bug is not minor.
Assignee: sspitzer → ducarroz
Severity: minor → major
Component: Mail Window Front End → MIME
QA Contact: olgam → gayatri
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.
QA Contact: gayatri → laurel
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.
OS: Linux → 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.
Summary: Mail Window: all headers are shown as forward headers → With 'Headers > All', forwarded message (non Normal) headers display/show parent (= Sent/Received) headers instead of the forwarded one, in Mail Window (both 3-pane/stand-alone)
Summary: With 'Headers > All', forwarded message (non Normal) headers display/show parent (= Sent/Received) headers instead of the forwarded one, in Mail Window (both 3-pane/stand-alone) → With 'Headers > All', forwarded message (non Normal) headers display/show parent (= Sent/Received) headers instead of the forwarded ones, in Mail Window (both 3-pane/stand-alone)
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".
Attached file Suggestion to patch DumpRestOfHeaders() (obsolete) (deleted) —
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?
Attached patch Daniel's patch (obsolete) (deleted) — Splinter Review
Patch based on Daniel de Wildt's suggestion in comment 20.
Attachment #134321 - Attachment is obsolete: true
Comment on attachment 134475 [details] [diff] [review] Daniel's patch Seeking review and super-review.
Attachment #134475 - Flags: superreview?(bienvenu)
Attachment #134475 - Flags: review?(neil.parkwaycc.co.uk)
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.
Attachment #134475 - Flags: review?(neil.parkwaycc.co.uk) → review+
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!
Attachment #134475 - Flags: review+ → review-
Attached patch Fixed DumpToCC (deleted) — Splinter Review
I did wonder about that... btw this diff contains other cleanup.
Attachment #134475 - Attachment is obsolete: true
Attachment #134484 - Flags: superreview?(bienvenu)
Attachment #134484 - Flags: review?(GotFrenchFries)
Comment on attachment 134484 [details] [diff] [review] Fixed DumpToCC The patch is good.
Attachment #134484 - Flags: review?(GotFrenchFries) → review+
Comment on attachment 134484 [details] [diff] [review] Fixed DumpToCC sr=bienvenu
Attachment #134484 - Flags: superreview?(bienvenu) → superreview+
Whoops, forgot to mark this fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Blocks: 222652
Attachment #134475 - Flags: superreview?(bienvenu)
*** 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. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: