140532 - 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)

Status: RESOLVED FIXED

(MailNews Core :: MIME, defect)

Description

[Stefan Helfert]

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.

Comment 1

[Ben Bucksch (:BenB)]

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

Comment 2

[timeless]

this bug is not minor.

Comment 3

[Stefan Helfert]

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.

Comment 4

[Daniel de Wildt]

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.

Comment 5

[Daniel de Wildt]

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)

Comment 6

[Stefan Helfert]

Changed OS to all.

Comment 7

[R.K.Aa.]

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

Comment 8

[R.K.Aa.]

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

Comment 9

[R.K.Aa.]

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

Comment 10

[Julian Hall]

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

Comment 11

[Rob North]

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

Comment 12

[Christian Hernmarck]

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.

Comment 13

[Serge Gautherie (:sgautherie)]

Attachment: Screenshot, to illustrate what is described in comment 11

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

Comment 14

[Serge Gautherie (:sgautherie)]

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.

Comment 15

[Douglas Robertson]

This is still an issue in 1.4 final and 1.5a

Comment 16

[Mike Cowperthwaite]

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

Comment 17

[Mike Cowperthwaite]

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.

Comment 18

[Mike Cowperthwaite]

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

Comment 19

[Daniel de Wildt]

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

Comment 20

[Daniel de Wildt]

Attachment: Suggestion to patch DumpRestOfHeaders()

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

Comment 21

[Otto J. Mäkelä]

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?

Comment 22

[Daniel de Wildt]

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

Comment 23

[Otto J. Mäkelä]

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?

Comment 24

[Simon Paquet [:sipaq]]

Attachment: Daniel's patch

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

Comment 25

[Simon Paquet [:sipaq]]

Comment on attachment 134475 [details] [diff] [review]
Daniel's patch

Seeking review and super-review.

Comment 26

[David :Bienvenu]

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 27

[[e-mail]]

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 28

[Jean-Francois Ducarroz]

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!

Comment 29

[[e-mail]]

Attachment: Fixed DumpToCC

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

Comment 30

[Jean-Francois Ducarroz]

Comment on attachment 134484 [details] [diff] [review]
Fixed DumpToCC

The patch is good.

Comment 31

[David :Bienvenu]

Comment on attachment 134484 [details] [diff] [review]
Fixed DumpToCC

sr=bienvenu

Comment 32

[[e-mail]]

Whoops, forgot to mark this fixed.

Comment 33

[Mike Cowperthwaite]

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

Comment 34

[Mike Cowperthwaite]

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

Comment 35

[Mike Cowperthwaite]

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