Both the persistent View All Headers mode and the All Headers popup show each header only once. However, some headers, especially "Recieved", can (and do) appear several times in a single msg. Reproduce: Compare the All Headers View with View Source of a mail. Relevance: One of the most common uses of the All Headers Views are to check the path of a msg. To make that possible, each server adds a new "Recieved" header at the top. Mozilla only shows the first server (lasted "Recieved" header in the msg), completely defeating the purpose of these headers. However, this is not obvious, so the user might miss the other headers. This might equal data loss.

- per mail triage. Not need for Netscape's beta 3.

[dataloss] -> rtm [if possible] nsbeta3- -> helpwanted.

rtm-, seems like you've stated the workaround for these people - use view source for that purpose.

yep, still see this using 2001.03.12.05 [moz on linux]. clearing milestone [which was set back in August 2000] so that this can be reconsidered for mozilla0.9. thx!

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

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

Hello, Just wanted to 'ping' this bug, and add that I'd like to request that the whiteboard include the dataloss keyword again, and the summary be changed to include the words "view", "all", and "headers", like the menu says. This latter change because it took me some time to find this bug. The reason I'd like to request 'dataloss' is because I just got some spam, and my mail server implements some spam filtering rules. For various rules, it adds values, and then rejects (in theory, not yet 'turned on') the message if some threshold is exceeded. This is what Mozilla (2002012708; Linux) states: [...] X-Exim-Spam: MESSAGE REJECTED: Score 105 > 99 X-Exim-Warning: Potential SPAM <grr ... must add new bug about not being able to copy and paste text> and this is what mutt reports: [...] X-Exim-Spam: Rule 2 (+20): HTML message (cumulative: 20) X-Exim-Spam: Rule 4 (+85): Dear Friend, (cumulative: 105) X-Exim-Warning: Potential SPAM X-Exim-Spam: MESSAGE REJECTED: Score 105 > 99 and nicely, mutt does this without me having to go into 'Full Header' mode. Where is my View->Headers->Like Mutt option? : (

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

Still present in 0.9.9 {Build ID: 2002031104}.

I've tracked this bug down to the processHeaders routine in msgHdrViewOverlay.js. The currentHeaderData variable is implemented as a hashtable and contains an entry for each headerName found. The problem of course lies in the fact that it executes the lines (lines 291-302) var foo = new Object; foo.headerValue = headerValues[index]; foo.headerName = headerNames[index]; ... currentHeaderData[lowerCaseHeaderName] = foo; once for every header found. The problem is that when there are multiple headers with the same exact name in a message like the Received header, subsequent Received headers overwrite the contents of the prior Received header entry in the hash table. The headerValue portion of currentHeaderData really needs to implemented as an array of values with one entry for each matching header found. That way, currentHeaderData[received] = [ "Recd line 1", "Recd line 2"]. Also, the UpdateMessageHeaders function (lines 507-555) will have to be updated to deal with the new approach of array of values instead of just a pure value. See references to headerfield.headerValue in lines 522 and 539.

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

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

Adding 4xp keyword as NS4.x used to display all Received: headers.

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

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

According to RFC 2822, there are at least 10 headers and 3 further types of header that can occur "unlimited" times in a correct email header. The "Received" field is one of the ten specific named headers that can (and often do) occur multiple times. Quoting from the RFC, the following 3 classes/types of field also may occur unlimited times: Header: Min-times Max-times: comments 0 unlimited keywords 0 unlimited optional-field 0 unlimited

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

This bug is still present in Mozilla 1.1 final for HP/UX, build id Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.1) Gecko/20020827. Is there a chance to get this bug fixed in a foreseeable future?

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

I have a patch for this bug, I will post it soon for review.

This patch offers one entry for each duplicate header by adding index after its headerName, so that the new duplicate header data will not overtake the old ones. Please review it.

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

I tried Richard Li's patch(Attachment 100970 [details] [diff]). It works fine with 2002100108-trunk/Win2k.

Thanks Koike for his test on my patch. Since it seems that the patch works well, how can I push this patch for review? Thanks.

> how can I push this patch for review? http://www.mozilla.org/hacking/ mscott or sspitzer would probably good reviewers.

Adding sspitzer to cc seeing mscott should already be on it and adding review keyword and removing helpwanted keyword

Really assigning it

Comment on attachment 100970 [details] [diff] [review] patch1 Thx for the patch, Richard.r=henry

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

This bug is still present in mozilla 1.2 UA: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126

Since this bug is still present in Mozilla 1.2, someone please super review my patch. Thanks!

Comment on attachment 100970 [details] [diff] [review] patch1 Seth, please take a look at this patch. Thx.

Comment on attachment 100970 [details] [diff] [review] patch1 I don't think we need to use multiIndx. all we need is for the header name to be unique. I think we can do: [lowerCaseHeaderName + index] testing it now, and fixing the comments...

Comment on attachment 108892 [details] [diff] [review] testing now... r=sspitzer on the core change, which is from the original patch. I'll ask bienveu to sr the whole thing.

Comment on attachment 108892 [details] [diff] [review] testing now... sr=bienvenu

Comment on attachment 108892 [details] [diff] [review] testing now... seeking approval

The new patch can work, as good as the old one. However, the new patch is a little hacking, and is not as readable as the old one.

I disagree that my patch less readable and more hacky. feel free to send me direct mail if you want to discuss it. marking fixed. thanks to richard for the initial patch.

Comment on attachment 108892 [details] [diff] [review] testing now... not a 1.3a blocker, removing approval request.

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

This is still present in 1.3a; "fixed" seems like the wrong resolution.

Has the patch been checked in?

I definitely see multiple "received" lines in nightly build 2002121608 (wow, I'm behind the times!). I would say its fixed.

I agree that it is fixed too in BuildID 2003010108, when I switch the View, Headers to All I see all the headers. Dan if you mean the lines are truncated (i.e. do not wrap at the end of the line) then that is a separate bug I've just logged as bug 187580

No, I meant that it's not fixed in 1.3a, but it looks like that was cut before Ian's build that has the fix, so I'm assuming it will make it into 1.3b. Thanks for checking.

OK Using jan6 commercial trunk: win98, mac OS 10.2, linux rh8.0

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

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

Using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040714 I see only two Received headers. That's better than one, but still a big loss of information. I openened bug 254637 for this problem.