260630 - Mozilla 1.7.2 Mail "To" Header will not print following upgrade from 1.6

Status: RESOLVED EXPIRED

(MailNews Core :: Printing, defect)

Description

[Jay Smith]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040814
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040814

Since we upgraded from Mozilla 1.6 to 1.7.2 (and to using Xprint) on Red Hat 8
Linux, the "To" mail message header (NOT the page headers) will not print.  The
Subject, From, and Date do print properly.  The "To" header IS visible on screen
while viewing the message.  However, the "To" header is NOT present in the Print
Preview, or when printing via Xprint or via the native Mozilla postscript method.

Reproducible: Always
Steps to Reproduce:
1. Print mail message

Actual Results:  
The "To" header line is NOT present.
The "Subject, From, and Date" lines are present.

Expected Results:  
There should have been four header lines, including the "To".

I have googled the web for other cases, and for hidden preferences. I have
posted on newsgroups.  Nobody seems to have the same problem.

I am aware of the Xprint font problems with PAGE headers (missing spaces and
numerals) and we have fixed that by moving the Xprint font directory aside.
However that seems to have no relation to this issue.

We are also unable to get the mail messages USING XPRINT to print with
fixed-width fonts.  In order to print fixed-width, we have to use the Mozilla
native postscript printing method (but we have other problems with that and
can't use it).

However, THIS issue is the same in preview, printed by Xprint, and printed by
Mozilla postscript.

This is a "major" problem because the paper documentation of the sender and the
sender's email address is lost.

Note: We stared years ago with LINUX Netscape 4.72 (Red Hat 6.x) and then
upgraded to LINUX Mozilla (I think 1.2?), then 1.4? (Red Hat 8) then 1.6 and now
1.7.2).  These were all upgrades in a multi-user environment -- they were NOT
completely clean installs.

I have tried adding a new user and starting Mozilla and setting up basic
preferences.  Even for this completely new user, the problem is the same.  Thus
IF this problem is related to "upgrades" rather than new installs, the problem
is at the "server level" and not something in the user's .mozilla directory
structure.

Comment 1

[Jay Smith]

We have now tested a Mozilla 1.7.3 (kde-redhat build) on Red Hat 8 and find the
same results (the "To:" header will not print).

I sure wish somebody out there would comment about this.  We feel like we are
going nuts.

If this is only a RH8 issue, maybe there is nobody left out there running RH8.
However, I don't understand why something like this (missing only one header)
would be _only_ an RH8 issue.

Jay

Comment 2

[Jay Smith]

I just remembered a couple other little tidbits that might help to diagnose this:

A) The "To:" header has always been the fourth header of the "normal" headers
that used to print (Mozilla 1.6 and previous).  Someone suggested that the fact
that it was four out of four (i.e. the last one) could have something to do with
the problem.  Maybe there is a "limit" of three headers somehow?

B) When more than the usual/normal four headers are visible on the screen (i.e.
an explicit "Reply To:" or "Organization:" [which I have turned on in the
prefs], those do NOT print now (they used to in 1.6 and before).  Again, this
suggests a limit of three lines to be printed??

Jay

Comment 3

[Jay Smith]

One more observation which may mean something:

Before the upgrade from 1.6 to 1.7.2 when **SOME** (but not all) of our users
would print an email, the "To:" header line had a shaded gray background whereas
the other header lines had no background shading.  

When other users printed, they did have the "To:" header present; the background
of that line was not shaded, however.

This suggests that there _might_ be some CSS used to control that appearance --
that one header line would have shading, but others would not. That then
suggests the possibility that something having to do with CSS controlling
visibility (or, in our case, invisibility).

Any suggestions of where such CSS or preferences might be located and what they
would be called?

Jay

Comment 4

[Jay Smith]

I started poking around and found:
http://lxr.mozilla.org/mozilla/source/mail/base/content/msgHdrViewOverlay.js#98

Which states:
// Our first view is the collapsed view. This is very light weight view of the
data. We only show a couple fields.

var gCollapsedHeaderList = 
 [ {name:"subject", outputFunction:updateHeaderValueInTextNode},
   {name:"from", useShortView:true, outputFunction:OutputEmailAddresses},
   {name:"date", outputFunction:updateHeaderValueInTextNode}
 ];

I don't pretend to know what I am looking at, but, this seems to state that the
default/initial view does not include the "to".

IMPORTANT: On our Mozilla 1.7.2, the View, Headers, All/Normal did not work
(i.e. it was stuck on normal).  I asked in that bug if the fix to that bug would
affect my missing "to" problem and was told no.

However, if the default/initial does not include "to" (BUT IT IS ON THE SCREEN)
and if the "switch" between Normal (without "to"??) and All was broken, I wonder
again if that bug could be related to my problem.

The .js file referenced above does not seem to directly relate to printing.
However, if the stated default/initial doesn't get the "to", then it would not
be available for printing.

Is there a way to test this?  Or does the whole program have to be recompiled?

Jay

Comment 5

[Jay Smith]

There has seemingly been no action on this.  Does anybody have any suggestions? 

Jay

Comment 6

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 7

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.