142513 - Text prints blue if printing backgrounds is disabled

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Oliver Klee]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+)
Gecko/20020504
BuildID:    2002050408

Text prints blue instead of black if "Print Background (colors & images)" is not
checked. The problem is visible in Print Preview as well

Reproducible: Always
Steps to Reproduce:
1. Visit any URL with black text, e.g. http://www.mozilla.org/
2. File/Page Setup...
3. Uncheck "Print Background (colors & images)" if it is checked.
4. Print (or use Print Preview).

Actual Results:  The text is printed blue.

Expected Results:  The text is printed black.

Comment 1

[R.K.Aa.]

added comment about this bug in bug 140679

Comment 2

[Oliver Klee]

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

Comment 3

[rods (gone)]

don, seems related to background printing

Comment 4

[dcone (gone)]

Is the text originally blue.  If it is.. that is what is supposed to happen.

Comment 5

[Pascal Chevrel:pascalc]

No it isn't. Why filing a bug if the original text were blue ?

Comment 6

[Oliver Klee]

The text prints blue regardsless of its original color (be it black, green, red,
or blue). I'll attach a small test case for red text.

Comment 7

[Oliver Klee]

Attachment: Test case with red text

Comment 8

[parish]

Although I was seeing this as well, it has disappeared now. CVS build
2002-05-40-10 WinXP

Comment 9

[Stephen Moehle]

The bug is still present for me.  I even created a new profile.

Mozilla trunk 2002-05-06-04 on Win2000.

Comment 10

[dcone (gone)]

The text will be darkened on a color printer.. when i run the test you put in 
this bug.. it works fine.  You can also see how this looks in print-preview.  If 
its red text (darked) when in print preview.. then something is wrong with the 
printer.  I get red with print preview or printed on my color laserwriter, 
windows NT and windows 2K.

Comment 11

[Stephen Moehle]

When I try the testcase in comment #7, I get blue text both in print preview and
when printing using today's trunk build.  If look at the same testcase in NN4, I
get red text in both print preview and when printing.  This is on Win2000.

Comment 12

[Pascal Chevrel:pascalc]

I still get blue text as well both in Print Preview mode and when printing,
using  Moz 2002-05-06-04 on W98SE. Dcone, how could this be a problem with the
printer if we get this problem in print preview mode ? Besides, if I redirect
the output to a pdf file (using a PDF virtual printer), I also get a pdf file
with blue text.

Comment 13

[Pascal Chevrel:pascalc]

Attachment: Screen capture

Screen capture of print preview mode

Comment 14

[parish]

OK, I've just tried this with 2002-05-06-08 (trunk) nightly on my W2K machine
here at work and it is still blus in both Print Preview.

I will try this same build under WinXP and my CVS build under W2K at home
tonight and report the results, but it is looking like this problem does not
affect WinXP.

Comment 15

[parish]

Doh! My previous comment should have read:

...it is still blue in both Print Preview and on paper....

Comment 16

[dcone (gone)]

pascal: Thats what I was trying to point out... if the print preview works.. 
then its a printer problem.. if both are blue.. then its not.  So everyone who 
sees this bug.. is telling me that all there print previews.. all the text is 
blue by default.. (assuming you left the print background in the default state)?
Using my Window NT and Windows 2K machines.. I can not duplicate this.  
I am assuming that all the problems your having all show up under printpreview..

Comment 17

[Pascal Chevrel:pascalc]

I've just tried it on a fresh WinXP partition with a new profile and build
2002-05-07-05 and I get the same bug I get with Win98.

dcone: are you sure that the "print background" option in Page Setup is
Unchecked ? The bug appears only if you have this option unchecked.

Comment 18

[dcone (gone)]

I have run on a few machines, and I do check to make sure backgrounds is off 
(which is default) .. and I am pretty sure there would be a huge number of 
complaints in print preview if this were the case... so what I am thinking is 
that you might be in some graphic mode.. like.. how deep is the display are you 
using, or do you have some special graphics card, or why did  parish's build 
just start to work.  The only other thing I can think of.. I use HSV color space 
to convert a color.. which uses floating point.. is there something about your 
machine that messes with the floating point stuff.  Do you build yourself then 
you can put a break point in nsColor NS_HSV2RGB and see what is happening.  I 
can only think that an error in that code is causing this problem, and for some 
reason it hits your machine and not mine.

Comment 19

[Pascal Chevrel:pascalc]

My Graphics card is an NVidia GeForce3 Ti200 (with the latest drivers) with
16bit display. I have an older PC with a SIS chipset, I am going to install
mozilla on it to see if I can reproduce the bug on this one.

Parish's last message was "it is still blue in both Print Preview and on paper"
so I believe the bug is not fixed for him.

Comment 20

[Pascal Chevrel:pascalc]

Done. I've just tried on this older configuration with an integrated SIS 6326
chipset and I still see print preview with blue text ! 

Comment 21

[Frederic Bezies]

Confirm this bug ! Have it since 2 or 3 days. Currently using 2002050705 - WinXP.

Is there a new trunk build available ?!

Comment 22

[Stephen Moehle]

For what it is worth, this bug was introduced on 4/25.  The last good build on
the trunk is 04-25-10.  It is broken and blue in 04-26-08.

Comment 23

[parish]

I've just d/l and installed the 2002-05-06-08 (trunk) nightly and the problem
appeared under WinXP.

I uninstalled that, and re-installed my CVS build and the problem disappeared again.

So, I have a build here, from 2002-05-40-10 and built under WinXP, that works
consistently. When I build I also build the installer as well (and use that to
install my builds) so if anyone would like to try this build I can put it on an
FTP site.

Comment 24

[parish]

I've put my CVS build at ftp://users.freebsd.org.uk/pub/mark if anyone wants to
try it.

Comment 25

[dcone (gone)]

I have had three developers try to duplicate this problem on there machines.. 
using the red text test case in this bug.. and it works just fine.  There has to 
be something on the machines that are broken that cause this.  April 24-26 time 
frames .. there are not any checkins that I did that would have changed how we 
print text.. so I have not a clue what thats about.

Comment 26

[Oliver Klee]

I don't think that this bug has much to do with screen display: Printing without
using Print Preview produces blue text for me as well (e.g. printing to the
PostScript file I attached).

Comment 27

[Stephen Moehle]

OK.  Show-and-tell time.  I have seen this on two machines running Win2000.
1) Dell OptiPlex GX300, PIII, nVidia TNT2 M64 with the latest drivers from Dell,
Adobe Acrobat PDFWriter printer driver.
2) Gateway, Athlon, nVidia TNT2, HP 842C inkjet printer driver with latest
drivers from HP.

On the Dell, I have tried both NN4 and IE6, and neither one exhibits the blue text.
The Gateway is a dual boot machine with Linux, and recent trunk builds do not
exhibit the blue text under Linux.

Comment 28

[parish]

OK, I've tested both the 2002-05-06-08 nightly and my own CVS build under both
W2K and WinXP, dual booting on the same machine, with both an existing profile
and a new profile, in 16-, 24-, and 32-bit colour using Oliver's test case and
the results are the same for both OSes using both profiles, at all colour depths:

2002-05-06-08 nightly: Blue text in both Print Preview and on paper
My CVS build: Red text in both Print Preview and on paper

The machine is an Athlon 700, 512MB, Abit KT7 m/b Via chipset, ATI Xpert@Work
4MB PCI card using the Windows drivers in XP and patched Rage LT drivers in
Win2K (because the standard drivers reverted to 60Hz every time I rebooted).

The printer is an HP Deskjet 610C using standard Windows drivers in both OSes.

The only significant thing I can see is that my CVS builds started working when
I started building on XP.

BTW, as dcone noted in comment 10, the red in the test case appears darker in
Print Preview and on paper than in the browser.

I think it would be worth others trying my build and seeing if it works for them
(see comment 24 for location).

Anything else you'd like me to try?

Comment 29

[Stephen Moehle]

The CVS build in comment #24 works OK for me with correct colors in both print
preview and printing.

Comment 30

[parish]

I've tried my CVS build on my W2K work machine and it works correctly here as well.

Comment 31

[parish]

From comment 18, dcone: "The only other thing I can think of.. I use HSV color
space to convert a color.. which uses floating point.. is there something about
your machine that messes with the floating point stuff."

I've just realized something which may explain why my builds are working on XP
although they didn't when built under W2K. The build instructions at
http://www.mozilla.org/build/win32.html say to install the VC++ Processor Pack.
I did this under W2K but I didn't bother under XP. I thought that the Processor
Pack was only required to get ml.exe, the MASM Assembler, so on XP I simply
copied ml.exe to the VC++ bin directory.

The Processor Pack adds SSE/SSE2/3DNow! instruction support which, of course,
affects floating point operations.

Tonight I'll install the whole PP, rebuild Moz, and see if it breaks my build. I
don't think anyone who is investigating this will be able to test this without
re-installing VC++ because, IIRC, there is no uninstall facility with the PP.

Comment 32

[dcone (gone)]

OK.. I have a theory.. there have been lots of GAMMA changes lately.. and I am 
wondering.. if that could account for the differences we are seeing on different 
machines.  I will investigate some more.. but I am betting that this may be the 
cause.  My idea is this:  The TransformColor() call transforms the red color 
into a darker red.. which then probably (not sure about this part)... goes to 
the gamma correction.  This maps it to blue.. correcting for the device.. this 
is just a guess but its the only way I can account for all the differences 
between machines. 

Comment 33

[Kevin McCluskey (gone)]

The GAMMA correction changes were backed out of the trunk several days ago. They
were never put on to the branch.

Comment 34

[Kevin McCluskey (gone)]

I see the blue text when print previewing www.mozilla.org using a trunk
2002050708 build on WinXP.

Comment 35

[Kevin McCluskey (gone)]

I see black text when print previewing www.mozilla.org using a 1.0.0 branch
2002050706 build on WinXP.

Marking nsbeta1- since it appears to be fine on the branch.

Comment 36

[dcone (gone)]

Attachment: Patch to test.

If you have a this problem.. and can build, try this one line change and see if
the text turns to the right color.  thanks

Comment 37

[parish]

I've installed the VC++ Processor Pack and rebuilt, under WinXP, and it still
works - I see red text in Print Preview and on paper.

As per other comments, it appears to only be a problem in the Trunk.

Comment 38

[Marcus Campbell]

Confirm blue text in Print Preview when "Print Background (colors & images)" is
not checked (2002050807, WinNT).

Comment 39

[mozilla.gv6r]

Confirm blue text in Print Preview when "Print Background (colors & images)" is
not checked (2002051308, Win98).  

"About:" shows
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020513
Mozilla 1.0.0+

Comment 40

[mozilla.gv6r]

Using "test case with red text".
Correct red text shows in Print Preview when "Print Background (colors &
images)" is not checked (2002051406, Win98).
Mozilla 1.0 Release Candidate 2
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020514

So, good in 1.0rc2 builds, broken in 1.0.0+ builds, as per Kevin M.

Comment 41

[dcone (gone)]

I know this bug exists.. could someone who has the bug.. please try the one line 
patch and see if it goes away.  I dont have a machine that will reproduce the 
problem.. thanks.

Comment 42

[Tony Fairbanks]

This is wierd..
I have a build that I made from CVS last night (5/13) at about 11pm. Using it, 
print preview and printing both print the correct colors. However, a build from 
ftp today (2002051408) DOES print in blue and print preview is blue as well.
So maybe its some sort of wierd VC++ problem? I'm using the same profile for
both builds so it isnt the profile, either. 
I'm using W2k SP2 with all the hotfixes, etc from WindowsUpdate
VC++ 6 SP5 with the processor pack

Comment 43

[parish]

Arghh! After not having this problem for ages, it's re-surfaced. CVS build
2002-05-11-02.

http://securityresponse.symantec.com/avcenter/venc/data/pf/w32.klez.removal.tool.html

The black text previews and prints blue and the hyperlinks, which are blue on
the screen, preview and print cyan.

I'll pull a new tree and rebuild tomorrow and see if it goes away again.

Comment 44

[parish]

Ref dcone's comment 18:
"Do you build yourself then you can put a break point in nsColor NS_HSV2RGB and
see what is happening."

OK, I've finally managed to get 2 builds from the same source; a debug build
which works correctly and a profiled optimized build which shows the problem.

Stepping through in the debugger it appears that the problem lies in NS_RGB2HSV,
not NS_HSV2RGB. The optimizer appears to be being too aggressive. In
nsCSSRendering::TransformColor() NS_RGB2HSV returns different values in the 2
builds:

nscolor
nsCSSRendering::TransformColor(nscolor  aMapColor,PRBool aNoBackGround)
{
PRUint16  hue,sat,value;
nscolor   newcolor;

  newcolor = aMapColor;
  if (PR_TRUE == aNoBackGround){
    // convert the RBG to HSV so we can get the lightness (which is the v)
    NS_RGB2HSV(newcolor,hue,sat,value);

Optimized:
newcolor == 0xff0000ff ; hue == 0x00f0 ; sat == 0x00ff ; value == 0xff00

Debug:
newcolor == 0xff0000ff ; hue == 0x0000 ; sat == 0x00ff ; value == 0x00ff

I haven't nailed down exactly what is wrong, but I'm working on it. If anyone
has any input/suggestions please let me know.

Comment 45

[parish]

Attachment: Disassembly of NS_RGB2HSV - debug build

Comment 46

[parish]

Attachment: Disassembly of NS_RGB2HSV - optimized build

This attachment and the previous one (84836) are the disassembly of NS_RGB2HSV
in both the optimized and debug builds. Maybe someone can see something
glaringly obvious in them. I'm getting a little out of my depth ;-)

BTW, my VC++ has the processor pack installed and I'm running an Athlon 700 so
could some the instructions be 3D Now! ?

Comment 47

[parish]

Attachment: Patch

I don't know if this is the correct solution, but this patch makes it WFM using
the same source as my previous build.

The NS_GET_* macros cast to a PRUint8 but r, g, and b, are (uninitialized)
PRUint16. This /should/ cause a straight integral promotion but who knows what
the optimizer is doing?

I didn't just add a cast to NS_GET_* as that would have created a double cast
which seems wasteful, although I guess we should use the macros since they are
there.

Comment 48

[parish]

Attachment: Test case with several colours

This test case uses several different text colours.

BTW, My previous patch includes dcone's patch from comment 36. This was also in
my previous builds and didn't solve the problem on it's own.

Comment 49

[Christian :Biesinger (don't email me, ping me on IRC)]

+  r=g=b=0;

that's redundant. you're setting all these vars again immediately afterwards.
why bother zeroing them?

Comment 50

[parish]

You're quite right; it's redundant. It was part of something I tried first but
forgot to remove afterwards.

Comment 51

[dcone (gone)]

so does that patch fix your problem.. I seems the 8 bit values are messing up.. 
so the cast should fix the problem.  If this fixes it.. I will r it and get the 
sr and check this in.

Comment 52

[parish]

Yes, as I said in comment 47 when I posted the patch. Since then I have removed
the patch, re-built and the problem re-appears, re-patched, re-built, the
problems disappears again so works consistently.

I haven't tried it on the latest tree yet.

Comment 53

[dcone (gone)]

Attachment: Can you try this.. basically the same but a slight variation. Thankx

Comment 54

[parish]

It didn't work :-(

After trying it I removed your patch and re-added mine, rebuilt, and it worked
again. As you say, your patch is basically the same except that it is making use
of existing macros. The only significant difference is that yours uses a double
cast, but that /shouldn't/ make any difference.

I am trying what I think is a better solution and will post a patch if it works
(it will take a couple of hours to build).

Comment 55

[parish]

Attachment: A more generic fix

This is a more generic fix - compile the whole function with no optimization.

The rationale behind this is:

1) The bug was not caused by changes to this function, NS_RGB2HSV()
2) It's reproduction is inconsistent (ref comment 18 and comment 25)
3) It appears to be a win32-specific bug
4) I can see no reason why my first fix (attachment 84861 [details] [diff] [review]), which is only doing
what the pre-processor {sh,w}ould do, worked and dcone's (attachment 86469 [details] [diff] [review])
didn't, even though the cast is strictly unnecessary since it is integral
promotion not type casting.

Given the above, I cannot see how my original fix can guarantee that this
problem, or similar, will not occur again.

This patch includes dcone's patch, attachment 86469 [details] [diff] [review], but without the ''()''
wrapping the macro as they are redundant because the whole macro definition is
wrapped  in ''()''. I have also tried this patch without dcone's, i.e with the
code "as-is", and it still works.

Comment 56

[dcone (gone)]

Attachment: Patch that just converts 8 bit to 16 bit signed.

I think this should fix things, and I use the signed values in the calculation
to prevent unsigned overflow.  Can you see if this patch fixes the problem..
thanks.

Comment 57

[parish]

Yes, that WFM on W2K

Comment 58

[Chris Waterson]

Comment on attachment 87202 [details] [diff] [review]
Patch that just converts 8 bit to 16 bit signed.

sr=waterson

Comment 59

[Kevin McCluskey (gone)]

Comment on attachment 87202 [details] [diff] [review]
Patch that just converts 8 bit to 16 bit signed.

r=[e-mail]

Comment 60

[dcone (gone)]

fixed on trunk

Comment 61

[Frederic Bezies]

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

Comment 62

[Boris Zbarsky [:bzbarsky]]

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

Comment 63

[sujay]

Oliver, can you verify this in latest build? let us know....thanks.

Comment 64

[Oliver Klee]

Sure. Verifying.

Comment 65

[Roland Mainz]

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