When viewing the image at the URL, Mozilla displays the background color of the GIF for the first frame, even though it is transparent. At the second frame, the background color disappears and stays gone through every subsequent loop. If this bug is confirmed, it needs to go as a blocker to bug 66967 Steps to Reproduce: 1. Change your default background color to something dark... like black. 2. Go to the URL above. or http://www.floralconceptsintl.com/images/pagelayout/A01.gif Expected results The first frame of the image (which lasts about 8 seconds) is a leaf on a transparent background. Actual Results The first frame of the image is a light yellow (the background chunk of the GIF) adn then the image goes transparent after the first frame (8 sec).

WORKSFORME OK system: Mozilla/4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) BuildID: 2001032614

2 additional testcase for your viewing pleasure. Debug menu -> Viewer Demos -> #2 Images Debug menu -> Viewer Demos -> #7 Scaled Anim Image Look at the little pair of eyeballs. White background at first, then black background for the rest of the cycles. You must close the browser (all Moz breowsers, not just one browser window) and load the page again in order to reproduce the bug. Reproduced the bug on Win98 using Win32 build 2001042820.

saari, i know we know about this one.. but wasn't sure if you already had a bug on it or not.

Confirmed with 2001-05-05-15-trunk on WinNT. The background colour appears, until the second frame is drawn, where it goes black...see next para for that. doctor__j's 2001-04-29 observation is another sighting of bug 77914, "Transparent animating GIFs have black background", distinct from this bug.

Windows specific

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

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

I believe a fix for this bug should also fix bug 77914 (Transparent animating GIFs have black background). In both cases it is the repainting which kills the background.

Actually This bug and the two I duped to it (and then retracted) have different symptoms but seem to be manifestations of the same or very similar problems. However, the symptoms are different enough to keep them separate.

Also occurs at http://business.netscape.com/business/

This one concerns an animated GIF, so it is a dup of bug 77914. Otherwise, I would send it to bug 83726 *** This bug has been marked as a duplicate of 77914 ***

This is NOT a duplicate of that bug. Lets explain the problem in question a little better. Transparent animated Gif files are all showing black as their background, this is true... but that is a different bug. During the 1.5days where that bug was fixed prior to its regression, This bug still existed. The problem is that every transparent gif has a color defind as a "background". In the case of this bug, this color is actually displayed instead of transparency for the first frame of an animated gif. So in other words, for that one day when the black background was fixed, the gifs all had a background chunk displayed (in my case a light yellow) and the subsequent frames (including subsequent loops) all had proper transparency. So once again, this bug is not a dup of bug 77914. It is entirely different. Also adding as blocker to 66967 and top100

Confirming Mike Young's explanation: Win98 build 2001061720 has the fix for bug 77914 (black background problem) but shows the background chunk on the first frame.

http://www.floralconceptsintl.com/images/pagelayout/A01.gif looks OK using Win32 build 2001061807. Probably fixed by solving the bug 77914.

I've been seeing this forever Now bug 77914 is a nice fix and does get rid of the black afterwards, but this is different. If you go to http://dsl.snet.net and look right under the top left of the screen where the animated 'DSL HOME' gif is, the first time it loads up you can see the rectangle outline of the gif. Watch the top left of the outline and you can see it leaves a white cut-out on the grey arch that's above it. The next time it animates, however, it is fully transparent and doesn't show again until you reload the page. This behavior I have seen for a long time. Still see this too on some messageboards with little animated similey faces. The first time they pop up (some) will have a white/yellowish backround, but the next time they animate it becomes normal.

I confirm this bug is not bug 77914. I do it as I was the guy who tried to dup it against 77914 in the first place ;-) To see it, you have to change the defauld background to something else than white. In my case unchecking "Use system colors" was enough to see the white backround of the first frame.

My apology... Jacek Piskozub was right. Changing background color to grey really did the job of revealing the damn bug. The white background seems to hide this bug from my eye... This is still not fixed...

I've created a test image that should demonstrate this problem much more clearly. (And at the same time demonstrate how serious this bug is.) :-) So long as you don't have red as your default background you will be able to see this test clearly. (If you do have red as your default, you will probably go blind very shortly and should seek help immediately.) The image is two frames, both black text on a transparent background. The first is 8 sec to exaggerate the problem (slightly but not by much... many banner ads do this) and the second frame is 3 sec. THere should be NO red in the image at all. (Red is the background chunk) Moz will display it for the first frame and then never again. To view it again, hit reload.

Mike: Can you explain why I (using 2001061809 on WindowsME): a) do not see any red (neither on the first or second frame) b) see the GIF change frames many fimes (not one as you claim). At the same time I see the white backround oa the first frame of the floral testcase...

I've been looking at the libpr0n code for Gif decoding, and I found an interesting function that seems as if it might have something to do with this bug. (My C++ experience is somewhat limited.) http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/decoders/gif/GIF2.cpp#691 here's a quote. For the first images in the sequence clear the logical screen to the background color, unless the first image completely covers the logical screen, in which case it's unnecessary. XXX - This can be optimized. I don't know whether this is it, but I figured I'd try to get this bug rolling. :-)

The attached test case has worked for me with 2001061720 & 2001061804 under Win2000Pro+SP1. I was still seeing Red :) with a build from a couple of days before (can't remember which).

Jacek: Well, truth be told, I was downloading 2001061804 as I made that test case. Unfortunately, I have a slow connection, and wasn't able to check what happens with this newest build. I can safely say now however, that this bug has morphed. We are no longer seeing the background chunk of the gif images. We are however seeing ... something ... The background chunk of the floral example is actually a light peach. The background chunk of the "No Red" example is Red. (Oh and sorry, the image loops. It has two frames 8 and 3 sec which loop to show that the "first frame" issue doesn't appear the second time around.) What we are seeing now is indeed some sort of background being applied to the images, but a background different from the GIF-defined background chunk. To me it almost appears semi-transparent like it is just a tint applied to the background of the page. (I looked at the image on a patterned backgound and it seemed like I could make out the pattern through the tint.) Whether this is just my imagination I don't know. For me, I can still see the red test image's background if I look at it without "system colors" in prefs. (That is really weird.) I've updated the summery to reflect this morphing of the bug. I still think it may be related to the background chunk and that piece of code I mentioned, but its going to take me a little while before I figure out exactly what's happening. Oh, and in my description of the testcase I say, "Moz will display *it* for the first frame..." it should read "Moz will display *the Background Chunk* for the first frame..." I think that might have been a little confusing. :-P

Not your imagination. The test case now gives me - a white image background when the page background is white - a peach image background when the page background is grey - a red image background when the page background is black - a semi-transparent peach image background when there's a background image on the page

P.S The "use system colours" pref doesn't appear to affect behaviour at all. The background chunk is just getting added to whatever background there is. black + red = red grey + red = peach white + red = white image + red = peachy image <disclaimer>non-programmer</disclaimer>

Darn these midair collisions!!!! Yes you're right. ------------ What we're doing is merging the background chunk of the GIF with the background directly below the image. This bug actually never changed. Since GIFs had black backgrounds, they were all showing their *full* background chunks. On a white page no GIF will ever display its background chunk. The testcase will help explain... With the red example, black = 000000, red = FF0000, background of first frame = FF0000 Green = 00FF00, red = FF0000, background = FFFF00 (yellow) the same goes all the way through. different shades of grey show different amounts of the background until you get to whith which is FFFFFF so nothing shows. With a patterned background I believe this is done for each pixel based on whats below it, leading to the semitransparent effect. It looks like it only happens if the background chunk is greater than the background so white backgrounds etc won't be affected. Changing summary again. Sorry about that...

OK. I see it now. The second testcase is much better. Actually I get red or pink on the black and gray squares even with white background. No need to change the default anymore.

Is the problem at www.tvguide.com caused by this bug? At that site the tvguide logo (upper left) has a white background for a few seconds (while the logo animation makes one full loop) until the background replaces it. Using build 2001062104 on WinME.

Wow, this looks a lot like bug 84980 for binary transparent PNGs. check out this test case http://bugzilla.mozilla.org/showattachment.cgi?attach_id=39549 Are they related?

Yes the TVGuide example is a case of this bug. I'm realizing more and more that this bug is much bigger than I originally thought. The reason that mozilla displays the background for 1 full loop of that Gif is because nothing ever overwrites the first frame. The day of the week is a smaller image played only in the center of the image. In theory it never has to refresh the outer part of the gif until it starts over. This means that the corruption of the first frame lasts throughout the entire animation. BTW the background chunk of that image is grey, for those of you testing on your own. Also, I am inclined to believe that this bug and the PNG Binary transparency bug are related very closely. Still Gif files are not affected however, which makes me think that something somewhere is getting binary transparency right. This also only affects the first frame drawn of a gif (And any remnants of it that are still visible during the animation) and the fixes for the two bugs may be very similar. But before any goes duplicating, these bugs are different enough to warrant seperate reports. :-)

mozilla0.9.2->mozilla0.9.3 nsbeta2->nsbeta1

->0.9.4 P1

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

-> 0.9.5

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

Same problem on W2k (2001122106) and some others weirdness (see attachment) (ok with IE or Irfanview)

over to nivedita

The reason why the background color was not transparent for first frame, in case of transparent animated gifs, was because for the first frame, we were filling the background of the frame with background color of the image. But for the subsequent frame's which is handled in DoComposite method of imgContainer class, we are filling it with zero's. Hence, from the second frame onwards we do not see the background color of the image. Calling FillWithColor with the color as zero rather than the background color.

Comment on attachment 67906 [details] [diff] [review] patch file for making first frame in transparent animated gif as transparent r=pavlov

Comment on attachment 67906 [details] [diff] [review] patch file for making first frame in transparent animated gif as transparent sr=tor

checked in