607631 - Some background images corrupted

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Bob Graham]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.41 Safari/534.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

You can see the html in the url above. Below is the css:


.tdTop
{
    width:700px;
    height:65px;
    background-image:url('../images/DataTop.png');
    background-position: center bottom;
    background-repeat:no-repeat;
}
.tdMid
{
    width:700px;
    background-image:url('../images/DatMidNoRepeat.png');
    background-repeat:no-repeat;
    background-position: center;
}
.tdBot
{
    width:700px;
    height:65px;
    background-image:url('../images/DataBot.png');
    background-position: center top;
    background-repeat:no-repeat;
}


Reproducible: Always

Steps to Reproduce:
1.create a table with three tr's and one td each
2. using a style sheet, set a background image for each (in may case they produce an expandable height drop shadow rectangle)
3.looks fine in IE, Chrome and Opera, discolors the middle image in Firefox.
Actual Results:  
Middle tr is discolored, using an oversize png as background-image or a 1 pixel tall 700px wide png with repeat-y.

Expected Results:  
See screen shot at photobucket link to see correct behavior vs FF behavior

Email me if you would like me to send the actual images, png files, html and css.

Comment 1

[j.j.]

Please test with latest Firefox 3.6.11 or Firefox 4beta6.

If the problem persists, attach a HTML testcase here (use the "Add an attachment" link above).

Comment 2

[Bob Graham]

Attachment: Just the simplest site possible that shows the problem

You can try it with the larger png file as the background for the .tdMid class or you can use DataMid3.png with the DefaultOther.css that use repeat-y to fill the td. Either way, in any way I try, I get the same color corruption in the middle td.

Comment 3

[Bob Graham]

Tried 3.6.11 and Beta 4 v6... same problem

Comment 4

[j.j.]

Attachment: image 1

Comment 5

[j.j.]

Attachment: image 2

Comment 6

[j.j.]

Attachment: image 3

Comment 7

[j.j.]

Attachment: reporter's testcase

Comment 8

[j.j.]

Attachment: reporter's testcase

Comment 9

[j.j.]

> Created attachment 486453 [details]

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11

No problem on 1.9.2 branch and current trunk with my machine (XP).

Comment 10

[Bob Graham]

OK, that's pretty irrelevant. This is to be deployed company-wide including a few execs who have a fondness for Firefox and run Win 7.

Comment 11

[Bob Graham]

Attachment: Confirm that it works fine in XP, although that is irrelevant

Again, someone needs to test this in windows 7. The misbehavior happens for me on both 32 bit and 64 bit Win 7 machines running the latest version of FF

Comment 12

[Boris Zbarsky [:bzbarsky]]

Bob, I just tried installing Firefox 3.6.12 on a brand-new Windows 7 install, and I can't reproduce the problem... 

I'll try a Firefox 4 beta once Windows finishes installing updates.

Comment 13

[Boris Zbarsky [:bzbarsky]]

I assume that on Win7 you see the problem when you load https://bugzilla.mozilla.org/attachment.cgi?id=486453 ?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Also no problem on that attached testcase using a current 32-bit windows trunk nightly.

Comment 15

[Bob Graham]

Boris, yes, I see the problem from your link. See newest attachment.

Comment 16

[Bob Graham]

Attachment: Shows problem exists when opened from Bugzilla link

For Boris, showing behavior directly from Bugzilla link

Comment 17

[Boris Zbarsky [:bzbarsky]]

OK, so I guess we need to figure out how your setup differs from mine....

Just to double-check, you see the problem in a clean profile?

Comment 18

[Bob Graham]

I can confirm that I have found one Win 7 machine that does not exhibit the problem. All three (the two I own that show the problem and someone else's that does not) are using NVidia graphics chip/card.

The two that show the problem are installed from a Technet subscription download of Win 7 Ultimate. The one machine that does not have the issue is running a Dell OEM copy of Win 7 Pro.

Very frustrating.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Hmm.  My machine is an HP OEM copy of Win 7 pro.

Bob, what's the value of the "gfx.color_management.mode" preference in about:config on the machine that shows the bug?  If it's not 0, does setting it to 0 make the problem go away?

Comment 20

[Bob Graham]

Aha, now we're getting somewhere. It was 2, changing it to 0 *DID* make the problem go away!

Now what the heck does that mean?

Comment 21

[Boris Zbarsky [:bzbarsky]]

The preference controls how the colorspace transformation from the image colorspace to the operating system colorspace is performed.  0 means "just copy the raw color channel values".  2 means "perform the correct color space transformation, but only on images that explicitly declare a colorspace".

What happens if you set the preference to 1 (which means "perform the transformation on all images, assuming sRGB if no other colorspace is declared by the image")?

Comment 22

[Bob Graham]

1 works correctly also. Is there some way I can code around this in asp.net?

Of disappearingly small importance, Safari also shows this behavior, though Chrome does not (despite both being built on the same engine). Do you happen to know (or care to tell me) if there's a fix in Safari?

Would using a gif file instead of a png change this behavior? I lean toward png files, but it would certainly be possible to use a gif file in this instance.

Finally, why is it that only the middle td is being affected? Does it behave differently when the whole image is displayed without repeat and without clipping?

Thanks

Comment 23

[Bob Graham]

Interestingly, the Win 7 Dell OEM machine that does not show this behavior has a setting of 2, which is apparently the default.

Comment 24

[Boris Zbarsky [:bzbarsky]]

> despite both being built on the same engine

They use totally different graphics libraries and have different paint-time behavior, for what it's worth.

I just looked at the actual PNGs here using pngcheck, and while the top/bottom ones have no colorspace information, the middle one has:

  chunk iCCP at offset 0x0003a, length 2639
    profile name = Photoshop ICC profile, compression method = 0 (deflate)
    compressed profile = 2616 bytes
  chunk cHRM at offset 0x00a95, length 32
    White x = 0.31269 y = 0.32899,  Red x = 0.63999 y = 0.33001
    Green x = 0.3 y = 0.6,  Blue x = 0.15 y = 0.05999

Note, by the way, that this is the only image that mentions photoshop; the other two claim to have been created by Adobe ImageReady.

So that explains why the middle image is the only one affected; it's the only one that has colorspace information.

The differences between the OS installs are then presumably due to different ICC profiles the OS uses in those different settings.

Using gifs would certainly change the behavior, since gifs have no colorspace information encoded in them.  But you could also strip out the colorspace information from the middle png there, or add it to the other two (possibly just opening them in photoshop and resaving?  Whoever generated the images hopefully knows how to do this part).  Basically, make sure the colorspace is the same for all three images. 

Marking this invalid, since we seem to be doing the right thing here, given the images in question.  Thank you for reporting this, though!  We'd rather end up with a not-a-bug resolution than an unreported bug.  :)

Comment 25

[Bob Graham]

Boris thank you for your help. 

I created the images, I'll figure out how to re-save the middle one without color-space info. The top and bottom ones were saved from the Photoshop "slice" tool, hence the ImageReady legacy nomenclature. I couldn't figure out how to do a 1 pixel slice, so I made the middle image with the 1 pixel row marquee tool in Photoshop.

On to my more important headaches!

Bob

Comment 26

[Bob Graham]

Attachment: Problem fixed in Photoshop

Boris, here's a screenshot with IE and FF, with FF color management back to its default setting. I used the "save for web and devices" command, but there's also a fix in the color management settings that corrected teh adding of a color-space that would probably make either save method work fine.

Thanks, Bob