I don't know where this bug should go, so I'm giving it to you (kipp) because you seem to deal with things quickly... and it'

(...not quite sure what key I pressed there...) Anyway... the bug: The background-image in the upper right has a transparency of some sort (I'm not an expert on this at all). However, the color that shows through isn't quite what it should be... it's a tad off.

this example lays out and displays vastly different in nglayout, communicator and ie. before rendering can be culpable, it looks like the layout needs to be different...

The stylesheet is browser-stiffed, so ignore the communicator rendering. You have to set NG_REQUEST_VER to 5.0 to get the page to display properly in NGLayout, since NGLayout by default reports 4.0 (still? I haven't checked recently). I sometimes forget to mention that, since it's in my autoexec.bat. I think the bug should go back to michaelp, so I am cc:ing him.

OK... here's that long line again, with returns. I just found another(!) bug in Opera 3.50. I do too much browser testing, I think. The stylesheet is browser-stiffed, so ignore the communicator rendering. You have to set NG_REQUEST_VER to 5.0 to get the page to display properly in NGLayout, since NGLayout by default reports 4.0 (still? I haven't checked recently). I sometimes forget to mention that, since it's in my autoexec.bat.

i don't see any problem with transparency, but there are differences in nglayout vs ie behavior. ie displays the "main" part of the document further down the page and when you scroll, you only scroll the main content, not the "fixed" background. i have no idea what is correct, but these issues need to be addressed before looking at rendering.

The two problems you mention are bugs 1045 and 1583. This is another bug and is independent of the other two.

And let me stress again that you must set NG_REQUEST_VER=5.0 in order to see this bug...

i've set the NG_REQUEST_VER to 5.0 but i *still* don't see any transparency problem. can you email me images of what you are seeing? what bit depth are you running your system at? does changing the bit depth change what you are seeing? what is the OS? it's marked "other."

First, I reassigned the bug back to michaelp. I am using windows95 with 16-bit color. An image of the problem is at: http://www.fas.harvard.edu/~dbaron/tests/nglayout/trans.bmp I drew a blue arrow where the problem is. It's a bmp because it needs the color depth... I think the problem may be that one of the two parts (the image or the document) is being mapped to a smaller color cube, and I didn't want to mess with jpg due to inaccuracy.

do you know if your video card is running 32768 or 65536 colors?

I assume it is 16-bit since I have seen drivers that give a 15-bit option. The video card documentation says 65K colors. It's an STB Velocity 128/4MB/AGB Bus. Can you see the bug in the image?

yes i saw the problem in the image, but not when viewing the page on my win95 box in 16bpp (my driver won't tell me how many colors, but i'm fairly certain that it's 565). i just checked in a change to how we do color selection in 16bpp that should fix the problem. i'll mark this as fixed and you can reopen it if you still see the problem with the latest code.

The bug still appears in the 12-16 build. The colors may even be a little more different, but I'm not sure.

i need another screen shot...

First, I'm changing the URL from http://www.webstandards.org/ie/ , which is a real site exhibiting the problem, to http://www.fas.harvard.edu/~dbaron/tests/nglayout/bgprob.html , which contains a series of simplified test cases. I have replicated the bug on my father's computer, since I am now home for vacation. Here are a few notes from the test cases (there are images linked to the test cases) 1) The problem only occurs with images that are set by CSS background-image. It does not happen with IMG SRC. I didn't try BODY BGCOLOR BACKGROND... - see the first of the test cases 2) The problem does not occur if the background color is set to a round value, like #FF0000 (red). See test 4 above. 3) If I save the screenshot as a GIF (256 color), the problem disappears in the 256-color image.

After some tests on the WaSP page, I found the following: If I set the BODY { background-color: } to #FF9000 (the original), the background of the image is shown as #FF9F00. If I set it to #FF9F00 or #FF8F00, the transparency comes out fine.

Setting all current Open/Normal to M4.

setting ELi as qa assigned to. I also checked in the most current win95 build and this is still a problem if you set the color palette to 16 bit, at 256 it looks fine.

Don, I am Reassigning image transparency issues to you.

I don't see any transparency problems. Comparing the test cases it looks good to me, some colors look mildly different (saturation off by a few) but that would not be a transparency problem. I checked a variety of depths. Marking as fixed. If the problems is still there, it would be nice to get a current and very exact description of the problem using the test cases set up by D. Baron.

From the description I'm assuming you were really resolving as WORKSFORME, and that you didn't fix anything on August 2. Therefore, on the basis of the August 1 build, I'm going to reopen this bug. I will attach an image with a description of what is going on written on the image. I'm beginning to think the problem may be something like that the imagelib and the rendering code use two different methods for rounding colors, and therefore the same color is being rounded to different values depending on whether the drawing is in the transparent region of the image or elsewhere. Of course, the image shouldn't really be drawing anything where it is transparent, because something could be underneath the image (although since there is a bgcolor, it's really OK, but only for background images... which may be what's happening).

Confirmed that bug still exists in 1999080908 (mozilla.org 1999-08-09-09-M9) on Windows 95. Thus this should definitely be reopened. Clearing fixed resolution, too.

-> m11. let me know if this is critical or a fix is in hand.

See bug 14147. That could be the cause of this problem...

There are some problems with the background colors when things are blended...

The render of gif images with transparency as background of tables have been improved a lot. But I still have problems in http://www.onirica.com . The first time all renders perfectly, but if you scroll the page, sometimes you get changed colours. I was using 2000030516 (a M15 nightly build) under NT 4.0 at 65k colours (16bit)

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

This bug has been marked future because we have determined that it is not critical for netscape 6.0. If you feel this is an error, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

My bug, http://bugzilla.mozilla.org/show_bug.cgi?id=14147 , was marked as a duplicate of this one, and we would be very disappointed to see this issue remain unfixed in the release of NS 6, especially after the problem has been resolved in both the Mac and PC MSIE 5.x releases. Please take a look at the following URLs to see how damaging this problem can be to page design: http://people.magnet.com/~lfrancis/colors/browsersafepalette.html http://people.magnet.com/~lfrancis/colors/colors.html

[no response seen from dcone regarding Lewis' comments; sent a reminder e-mail to dcone.]

If a way can be found to find the current bit order for the installed card..this could be fixed, but I can not find this call. The reason it is future is because I have about 50 bugs.. 7 of which can be fixed before release.. I was told to future anything that fell under this wire. If I fix those 7 and a few others.. this would then be back in the spotlight. I understand that this would hurt some websites but my other bugs have a high priority (like printing crashes, etc). Future does not mean this is not important, just means that we are down to the end of the wire for ship.

WebMonkey recently (September, 2000) published the article "Death of the Websafe Color Palette?" < http://hotwired.lycos.com/webmonkey/00/37/index2a.html?tw= design > and generated a lot of activity on SlashDot < http://slashdot.org/ article.pl?sid=00/09/08/1622204&mode=thread >. There's a fair amount of noise buried in these links, but I present them here as evidence of developer concern about this problem. Here's hoping those ultra-critical bugs can be taken care of and the spotlight can move back to this color matching issue.

Robert, this *may* be related to the view manager, so cc'ing you.

I just tried lfrancis' test page and it looked great to me (NT4, 16-bit color). http://people.magnet.com/~lfrancis/colors/colors.html Is this graphics-card dependent? Is it platform dependent? In any case, I think it is not a view manager problem. There aren't even any translucent views here.

David Baron's problem (which is what this bug was filed for) seems to be caused by the same compositor bug I described in Bug 51179. I am now WORRIED that lots of Netscape engineers have seen symptoms of this bug, and probably closed several like it "WORKSFORME" because they didn't have someone as persistent as me or David Baron chasing the bug. Plus, shouldn't there be some kind of prize for closing early 4 digit bugs like this one at such a late stage?

More info -- it looks like Microsoft handled this issue in Win IE 5.x by selectively dithering mismatched foreground gif and background colors in order to get them to match, albeit in a now dithered form. This strategy may be reasonable; it passes my test page at http://people.magnet.com/~lfrancis/colors/ colors.html but fails when attempting to seamlessly place non-dithering Flash content.

The testcases in the above URL http://www.fas.harvard.edu/~dbaron/tests/nglayout/bgprob.html no longer work ( images missing?) How does imagelib handle colors? Could the code be used?

The images for the testcase are in http://www.fas.harvard.edu/~dbaron/tests/nglayout/bgprob.tar.gz . They were taking up too much of my disk quota.

David Baron: the images that are inside the tar.gz file are screenshots The missing image is: http://style.verso.com/accounts/wsp/wasp_top_right.gif It has now been moved to http://www.webstandards.org/css/wasp_top_right.gif

i have a more visible example of the problem. http://www.emuhq.com/pn_test3/html/index.php scroll down to bottom of the page and scroll back up, there's 3 transparent background images that looses their transparency, and the transparent part turn black instead of white as it should be.

That is a different (and also known, I belive) bug. Please don't confuse this bug with other issues.

does anyone still see this bug? I can't see it anymore in build 2001081303 trunk on win98.

Do you have a 16-bit display? See bug 14147.

I still see the bug in the testcase from bug 14147 but not from the testcases in this bug.

I'm using linux build 1.0RC2 in 16 bit color depth and am _not_ seeing this bug in the test cases provided. Does it still exist?

It still shows for me in RC3 on Win98 using the testcase from bug 14147 (marked as a dup of this bug)-- please note that the company hosting this bug's testcase no longer exists; the demo can now be found at: http:// members.cox.net/lfrancis/colors/colors.html

I used the test case from comment 49.. in 24 and 16 bit mode.. and did not see the problem. NOW.. that being said.. if you can still find a problem that you feel was covered by this bug, can you open a new bug.. and explain exactly what you see. This bug is getting to long and confused.. and I want get an exact symptom, URL and configuration so I can duplicate this problem and solve or explain it. Thanks.

I just fixed the image URL in the original testcases in http://www.people.fas.harvard.edu/~dbaron/tests/nglayout/bgprob.html (style.verso.com is now style.cleverchimp.com).

Were you testing in Windows 95/98 or Windows NT/2000/Me? I think all the comments from people who saw this bug were in 15/16-bit color on Windows 95/98.

Reopening. I can still reproduce on cathleen's Win98 box (the one with no cover so the RAM chips can be changed more easily) by changing it to 16-bit color. (Setting Platform/OS correctly as they should have been set when I originally filed the bug, except bugzilla's platform/OS detection was somewhat broken at the time.) The only reason this bug is long and confusing is because it's been repeatedly closed and reopened. I've been able to reproduce it on every Win95/98 box with 16 bit color that I've tried on (and that's at least 2 or 3 over the history of the bug). You have to look closely. The testcase to use is the one from bug 14147, as comment 50 and comment 48 say, so changing URL field appropriately. Reopening for the third time.

Actually, on second thoughts, this should be worksforme, since the original problem (dealing with transparency) is fixed (perhaps by libpr0n?). However, we're still broken in the non-transparency case is still broken, so I'm going to reopen bug 14147.

v