Closed Bug 77914 Opened 23 years ago Closed 23 years ago

Transparent animating GIFs have black background

Categories

(Core :: Graphics: ImageLib, defect, P1)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: jefftl, Assigned: saari)

References

()

Details

(4 keywords, Whiteboard: top limbo candidate, possible rtm stopper, r=bradley & r=saari, sr=roc+moz, a=dbaron)

Attachments

(8 files)

The solution of bug 73979 may have fixed the animating gifs, but it seems that
the transparency now shows up as black, even when not on a black-backgrounded
page.  I have found this particular bug in build 2001042704.
Keywords: nsCatFood
Keywords: verifyme
I am seeing this with build 2001-04-27-09-ttunk w2k, also see that adobe.com 
still has an animating image problem as well :-(
Status: UNCONFIRMED → NEW
Ever confirmed: true
I believe you mean the solution to bug 73978.
Hmm interesting bug 73978 was fixed on 4/26, I saw it fixed on the 4/26 with no
black background, seeing the black background on 4/27 so could this be something
else ?
You are right. I installed 2001042604 to check this. Yesterday build had bug
73978 fixed but not yet this bug.
I'm seeing this with 2001042713 (0.9 branch) on Linux. I suggest changing
Platform/OS to All/All
I'm seeing this as fixed in build 2001042615, which I believe is named
incorrectly because they were put up on the ftp server on the 27th at 17:48:00,
whereas the builds from the 2001-04-27-14-trunk directory were put there on the
27th at about 15:30:00.  So, my build, even though it looks as if it is from the
26th, is really from the 27th and newer than what Frederic used.

I see no black background.  Everything looks normal in the animated gifs.  If
anything, there is an initial white background for the first frame.  Also, there
is one image that isn't animated that continues to have a white
background...maybe because it never goes past viewing of the first frame.

I'm on platform win2k

Jake
Your comment made me check all the recent Win32 installer builds. These are the
results (I'll skip 200104 in the builds names for brevity):

2404 to 2520 - *bad* black background, movement leaves trails 

2604 and 2615 (the latter both trunk and 0.9) - *good*! No trails, no black
background

2704 till today (actually there are three builds in catalogs named 2704, 2709
and 2714 all of then have 2704 in the title bar) - *regression* No trails, but
black background 

In short I do not believe 2604 is newer than 2704; I've seen many times old
builds appear on the FTP server with delay.
Issue still present in 2001043007 Windows (Installer) 0.9 RC Build.
Interestingly, this is NOT present in the Linux builds blizzard@ is using for
the RH7 Rpm's (tested as far back as 04/28 0.9 RC rpm's).
On 2001043004 Win2k trunk, GIFs that are used as UL graphics suffer the same
problem - see
http://www.informatik.uni-bonn.de/~prosec/inkonetz/workshops/beschreibung_2000.html

Is this the same bug or should I file a new one?
still a problem on 5/2 trunk builds...

this affects sidebar, we get a black square for the "loading icon"
*** Bug 79015 has been marked as a duplicate of this bug. ***
Keywords: verifyme
OS: Windows 98 → All
Hardware: PC → All
*** Bug 79138 has been marked as a duplicate of this bug. ***
There are many sites that suffer from this.

I have noticed this on sites like cnet, zdnet, and anandtech. Probably should
have top100 keyword.

Keywords: mozilla0.9.1
Setting top100 keyword.
Keywords: top100
*** Bug 79399 has been marked as a duplicate of this bug. ***
*** Bug 79440 has been marked as a duplicate of this bug. ***
*** Bug 79489 has been marked as a duplicate of this bug. ***
This seems similar to a bug I am seeing on http://www.alteridem.net, The
animated GIF at the top of the page displays correctly for the first frame, but
then successive frames which are supposed to display over top of the first frame
appear over a black background. Once the animation loops, the first frame once
again appears correctly and successive frames incorrectly.

In addition to this, one very strange thing is happening, when I click on
Customize... in the personal toolbar, it takes me to the Netscape page and the
graphic continues to display on the page. It does not appear at first, only when
the timer fires to load the next frame. If I scroll down on the page it moves up
with the page, but then when the next frame is drawn, it displays at the
original location on the page. This does not happen when I click on a hyperlink
or when I go to a bookmark.

I am using Mozilla 0.9, Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9)
Gecko/20010505 on Windows 98 SE.
*** Bug 79703 has been marked as a duplicate of this bug. ***
*** Bug 80441 has been marked as a duplicate of this bug. ***
*** Bug 80409 has been marked as a duplicate of this bug. ***
I keep getting duplicate reports on this...I'm adding keyword mostfreq to
reflect that.
Keywords: mostfreq
*** Bug 80862 has been marked as a duplicate of this bug. ***
saari, isn't this fixed?
Assignee: pavlov → saari
I still see this with 2001-05-16-04, Win NT.
strange happening ... at http://www.world-direct.com/central ... just move the 
mouse over one rectangle, the transparent animating gif has a white background!

seen with build 2001051604 on win2k
The loading.gif shows up black in the sidebar and ftp loading on windows.
it works on the mac.
Blocks: 81552
*** Bug 81954 has been marked as a duplicate of this bug. ***
High priority for 0.9.2
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.2
Any idea when this will get fixed ?
Probably next week barring unforseen things
*** Bug 82934 has been marked as a duplicate of this bug. ***
Using Mozilla/5.0 (Windows ME 4.90.3000; en-US; rv:0.9+) Gecko/20010524
also previous build milestone 9.0 did the same.
this is a NON-animating gif problem, if it should be reported to a seperate bug
report, let me know
the bacground image of a table cell (TD) displays Black, where transparent
should be. 
on this page http://justken.net/BandB/Homes/Inverness.html the burgendy and
black stripes should be burgendy and transparent. 

if the stipes apear with the background correctly displayed - reload the page,
and the black always replaces the underlying background.
I'm seeing this also in build 2001-05-29-04 win zipped format.
Animated gifs with a transparent background are showing
up with an ugly black background?

Reproduce:
Open resource:///res/samples/test2.html from the debug Menu. It's number 2 in
the viewer demos. 
Expected results: transparent background.
Actual results: black background.

The anieyes.gif when opened in PSP  Animation Shop 3.02, one sees that it is a
10 frame gif with transparent background, where as the gear1.gif animation has a
white background.

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

Why isn't this nsbeta1? It seems to me like something that's this visible should
be critical for the next public release. It would be extremely humiliating to
see this bug in a public release of Netscape.
nominating.
Keywords: nsbeta1
I'm working on this, and there are actually 2 bugs. A win32 specific one with
the GIF mask not being set up correctly, and an XP one where there are some
images that arn't rendered correctly.

http://justken.net/BandB/Homes/Inverness.html 
Is the win32 bug

http://www.alteridem.net/
Is the XP GIF animation bug
*** Bug 83563 has been marked as a duplicate of this bug. ***
*** Bug 83562 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Slipping back to mozilla0.9.3 :-( 
Let us be careful - this may be the most visible browser bug Mozilla has. There
was already one milestone release that had it. I am afraid about the bad
publicity it may reap.
Hi
Just wanted to report that this bug is
alive and unwell in: 

build id 2001-05-31-04
OP Win  
Format zipped
But in Netscape 6.01 public release this bug was not present! Why??
In Mozilla 0.81 release this bug was not present, too.
It is a fresh regression. It happened a few days before mozilla0.9 release and
was unfortunately checked in to the 0.9 branch. 

Thor this single reason I used a pre-0.9 bulid for several days after the
mozilla 0.9 release.
For those that don't keep up with Mozilla development.. it originated with the
landing of imglib2 (libpr0n).
*** Bug 80995 has been marked as a duplicate of this bug. ***
Aaron, I believe you are not completely correct. Libpr0n landed at the begining
of April (around 10th?). See my 4/28 comment. The bug was fixed on 4/26 but
regressed the next day. It was the 4/26 build I used just because of this bug.

Adding regression to the keywords.
Keywords: regression
Jacek is correct. This bug was fixed for about 1 day immediately after bug 73978
was fixed, then it regressed.

*** Bug 78114 has been marked as a duplicate of this bug. ***
*** Bug 83893 has been marked as a duplicate of this bug. ***
No change, still there in:
build id 2001-06-02-20 trunk windows zipped

steve
why in god's name is this pushed back to .93???? Netscape thinks it's a good 
idea to go forth with a beta with this issue?
It's still nsbeta1, Netscape knows better than to let something like this get
into anything even remotely public.

Of course, AOL doesn't...
Please stop spamming.

It is clear that gif transparency is messed up.

Since mozilla is open source, you can click on the "Create a new attachment"
link and add a fix.  I am sure saar (and/or other developers) would be happy to
help test and check the fix in for you. Otherwise, this is not helping. ;-)
Bug 84080 is related, maybe a dupe, but I'm not sure.
can we get status on this? sidebar loading icon is affected by this...
The status is that I started working on this, then it got triaged to 0.9.3. When
I'm done with my 0.9.2 bugs, I'll come back to it.
Keywords: testcase
*** Bug 84370 has been marked as a duplicate of this bug. ***
here is something interesting. Take a look at the slow animation I just
attached. It has two frames. The first is a yellow blob, and the second is just
a totally blank transparent frame. This animation has a very slow framerate.
about 10-seconds per frame. When the first frame loads we see noise-pixels of
random color all over the transparent area. After waiting about 10 seconds the
next frame loads, and from now on all the transparent areas are that plain blank
black we have all come to know and love. It seems that the first frame of ALL
transparent animating gifs display these scattered random pixels, its just that
it usually moves on to the second frame so fast we dont notice it (can anyone
else confirm or deny this?)
Well, with 2001060504 on win2k, I don't see any noise pixels on your attachement...
Older builds did do that.. now its just black.. Win2K/2001060620trunk
Yeah, I remember the older problem where that happened to all images, but thats
not what I am seeing. I am using build 2001060704 on Windows 95 when I see the
noise on the first frame of that slow GIF *shrug*
The strange pixels you see can be a separate bug affecting also non-animated
images. I believe it is related (or identical) to bug 82868. But it's true: I
haven't seen that behavior with recent builds.
*reads bug 82868* ... nothing in any of the comments on that bug even remotely
resemble what I described.
I can confirm MozillaUser@HamsterRepublic.com's experience on Win98 build
2001060604. I've noticed the first-frame corruption on all previous builds
(since imglib2 landing) on several other animated GIFs too. It just seems that
imglib2's handling of GIFs and PNGs is still broken - there at least two other
major things wrong that I haven't got the time (exams!) to raise a report for
yet (PNG transparent background not transparent, GIFs with transparent border
are scaled/translated as if border wasn't there).
True. GIFs and PNGs after libpr0n have a lot of problems (maybe we neet a meta
bug for them).

However, I believe the point of this bug is that transparent GIF background
being black after repaint  which happens during the repaint caused by the second
frame (the same for non-animated bugs when repaint is forced - bug 83726). 


With the new attachment, if you reload before the image switches, it 
reloads a completely black background. i have also found that if a page is 
loaded with a similar image, then the background is black, so before calling up 
the test page, make sure that your cache is clear, and you have not previewed a 
similar test cast prior to the load, or the corectly loaded image doesn't work. 
also susequent requests for that page will bring it up with the black 
background. also, using a test image with a partial transparent image, even the 
areas of the image that are white, display correctly.
cp: i've made the image larger, so that the semi transparent images are the 
same. 
i'm using win ME, build 201052404.
http://justken.net/samples/test2.html

also the first image, loaded correctly with no artifacting which i had on the 
attached image.
Check out bug 78114 for info on the first frame corruption.

What you are seeing is related to the fact that every transparent GIF file has
an inherent "background" color specified as transparent. In the case of your
GIF, it appears that the background color is undefined, which means it defaults
to black. Mozilla displays this background "chunk" for the first frame and then
goes to black. In your case, it seems mozilla displays noise then goes to black.
The problem is that all of these things are being overshadowed by this bug which
makes finding other problems very hard. 

I'd say comment on bug 78114 about it and once this bug gets fixed, we can see
whether that one still exists and if necessary, file a new bug. 
Can we consider moving this 41-vote, mostfreq bug to .9.2?  Let us know if this 
is possible, we'd like to remove the animated sidebar gifs if not...
Also note that the Modern theme throbber is affected by this bug (though it
should probably just be replaced with the Classic theme throbber..)
Actually, I cannot believe that something affecing the way Mozilla itself looks
- even if we forget the highly visible effect on some Web pages - is not even
nsCatFood+. Just as a reminder: nsCatFod is about "serious user satisfaction
issue with the product".

Adding mozilla0.9.2 keyword for good luck...
Keywords: mozilla0.9.2
I think this should be retargetted to 0.9.2 it is a highly visible bug, it got
fixed once, why cant it be fixed again ?
*** Bug 84898 has been marked as a duplicate of this bug. ***
I've got 2001060811 and I see no problems with either of the testcase
attachments above. This in on RedHat Linux 7.1.
I still see this bug on build 2001060920 (PC, WinME)
Right, saari commented here on 2001-05-31 13:41
that there were two bugs.  The two test cases attached
above seem to only cover the Win32-specific bug.  I'll
attach a test case for the XP bug to help with
verification.
Attached image XP bug testcase
"While we're at it", I have attached an animated GIF which is
problematic in another way.

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=37882

Saari, this GIF renders "right" in NS4 but I 60% suspect that
that's due to a NS4 bug and that Mozilla is doing the right
thing.  The problem comes around frame 7 when a #2 'replace'
disposal type is used for a frame which is a subimage.  Mozilla
and I and many decoders think that the new frame should replace
everything in the GIF screen while NS4 thinks that only the
area represented by the subimage should have its data replaced.
The GIF spec doesn't seem clear on the matter.

Let me know if that needs a new bug.


*** Bug 85177 has been marked as a duplicate of this bug. ***
Just talked with embedding PM, this should be considered a top limbo candidate,
and is being reconsidered for RTM showstopper status.
Whiteboard: top limbo candidate, possible rtm stopper
Here are a couple more sites which exhibit this bug:

http://www.barnesandnoble.com/ (Your Shopping Cart image and 1-Rate Shipping /
Save Money images)
http://www.pricecrazy.com (most of the images on the front page)
Wait a sec, I get pulled off this because it isn't considered a 0.9.1 level
issue, and now it is an RTM blocker potential?
 
At least I agree with this targeting. 
This bug was fixed for a day, untill timeless checked in the following one line
change(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=32358):


--- gfxImageFrame.cpp	2001/04/26 07:11:47	1.10
+++ gfxImageFrame.cpp	2001/04/26 23:30:56

-  if (!mInitalized || !mHasBackgroundColor)
+  if (!mHasBackgroundColor)
 
What was the point of this change. If only "simplify background logic" - see bug 
73798, 2001-04-26 16:37 comment by timeless, I would consider backing this one
liner   out.

"

http://www.pepsiworld.com shows this bug too.
that's an interesting arguement except that my patch was never committed.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx2/src/gfxImageFrame.cpp&
rev=1.10
as of today, 392 jelwell 1.10   if (!mInitalized || !mHasBackgroundColor)
is the current line.  The reason i suggested it is as follows:

mHasBackgroundColor will only be true if mInitialized

truth table:
mI mHB !mI !mHB (!mI || !mHB)
0  0    1    1       1
0  1    1    0       1        <- this case doesn't happen.
1  0    0    1       1
1  1    0    0       0

a quick look at the last two collumns of the truth table shows that they are 
equivalent if you remove the case that can't happen.
*** Bug 85275 has been marked as a duplicate of this bug. ***
Sorry Timeless for suspecting you ;-) But something checked in on 4/26 must have
caused the regression as transparent GIFs worked fine on all 4/26 builds but not
later (see my 4/28 comment). So maybe this problem was not caused by the fix to
bug 73979, after all...
Is this bug being looked at? Seems pretty bad to me.
OK. I found the check-in which created this bug! It was not bug 73978 but
unrelated bug 75641. On 4/26, 12 hours after check if for 73878, dprice checked
in the following code:

RCS file: /cvsroot/mozilla/gfx/src/windows/nsImageWin.cpp,v
retrieving revision 3.74
diff -u -r3.74 nsImageWin.cpp
--- nsImageWin.cpp      2001/04/04 08:23:14     3.74
+++ nsImageWin.cpp      2001/04/24 22:05:26
@@ -912,6 +912,11 @@
     mImageBits = nsnull;
   }

+  if (mAlphaBits != nsnull) {
+    delete [] mAlphaBits;
+    mAlphaBits = nsnull;
+  }
+

Commenting out the three lines on a fresh CVS build solves the problem :-)

It was a fix for a memeory leak. I found that bevause it changed one of the
files changed in the fix for #73978. The 12 hour difference explains why we
believed the reason is that chceck-in.

I'll continue testing the other transparent GIF problems with this build. 
I added dprice@netscape.com to the CC: list as his code created this regression.
The non-animated version of the transparent GIF problem (bug 83726) is also
solved with the tweaked build. It seems they both are the same bug, after all.  
It seems that we clear mAlphaBits wrongly after each frame. Shouldn't there be a
check on whether it would be needed again? As it is needed not only for animated
GIFs but also for repainting of GIFs with scrolling etc., it seems that we
shouldn't do it at all. Why other OSes don't clean up this array )(or its
counterparts), except on initialize and destruction of the nsImage[OS] object?
What makes Windows different?
it was someone's attempt to fix a leak.  I think my patch makes more sense but 
i haven't tested it (i'm rewriting graphics contexts to use modern strings so I 
don't have a working tree).  However, this bug is XP and a lot of complaints 
are about linux, so whether this fixes windows or not, it doesn't solve the 
whole problem.

otoh, AFAIK linux has always had the black background, qa/pavlov/tor: am I 
wrong?
Keywords: helpwanted, qawanted
Thaks Timeless! A build with the new patch runs fine on WinME. The bug is gone,
no visible side effects. I am not 100% sure about the memory leak.

It seems the (main) Windows problem introduced on 4/26 is solved. We need a r=,
sr= on this. I do not believe the Linux problems have anything to do with this.
The bug was wrongly changed to All/All. If there are still Linux problems, the
original Linux bug 73978 should be reopened or a new filed. Plese notice the
date this bug was filed - we found and fixed the reason for this originally
Windows bug.
Whiteboard: top limbo candidate, possible rtm stopper → top limbo candidate, possible rtm stopper, needs s=, sr=
Don't know if this is related to this bug, but at
http://www.world-direct.com/central
if you are moving over a rectangle the appearing 
transparent animated gifs have a _white background_ !

Using build 2001061104 .. but this behaviour is there
for a few weeks now (I believe as long as 77914)
So I'd like to say r=jag, and it certainly looks okay, but I'm wondering about
not delete[]ing mAlphaBits in CreateDBB(). And isn't cleaning up mAlphaBits
really part of CleanUpDIB (Clean Up Device Independent Bits)? In which case I
would question the CleanUpDIB() call in DrawToImage(...).

In other words, I don't know enough about this stuff to say r=jag with the
confidence needed.
*** Bug 85368 has been marked as a duplicate of this bug. ***
Linux has had this bug for quite awhile, but actually in yesterday's builds it
seemed ok...
Wouldn't adding the three lines deleting mAlphaBits to CleanUpDIBSection() be
more elegant? I have a feeling that jelwell created it exactly for thngs that are
not supposed to be delete[]d in DrawToImage().

Adding jelwell to CC:
*** Bug 85642 has been marked as a duplicate of this bug. ***
ok, so we have a regression caused by a bad leak fix by dprice r=pavlov 
sr=brendan.

brendan: i'd like an r or sr= from you and i'd like help finding someone else 
to give the other for this silly change. perhaps dcone?
I'll checkin whatever someone requests.  pavlov nicely refuses to review my 
tiny patch (I should have pointed out that he reviewed the code which i'm 
fixing but I didn't check before asking him).

i'd gladly take sr= from tor, roc or hyatt but i'm not picky.
Keywords: approval, patch, review
*** Bug 84719 has been marked as a duplicate of this bug. ***
The renown germany computer magazin CHIP is complaining about this bug ... 
http://www.chip.de/produkte_tests/unterseite_produkte_tests_167907.html

Do hope to get this one into 0.9.2
this REALLY should be in 0.9.2, especially since we already have a patch (which
also looks quite simple). 
I think we should trying to get sr=, r= and a= from somewhere :-)
http://www.eddie-rodriguez.com/english/home.html - this one looks as a garbage
with this bug... defenetly a 0.9.2 bug
The patch does not seem to fix the problem for me
Saari: which OS have you tried? For me, with WinME, all the testcases of this
bug and dups of the related non-animated GIF bug 82726 are gone. In fact I use
only CVS compiles for the last few days in order not to look at the transparent
GIF abominations any more :-(

However, it is clear that any Linux problems predating the 4/26 Windows-only
regression will not be solved by this Windows patch. This is why I ask about the OS.
Errr... Correction. I mean bug 83726 :-(
*** Bug 83788 has been marked as a duplicate of this bug. ***
W2K build 2001061404 still shows this bug.
Another example:

http://www.p-fankhauser.ch/indexframe.html
*** Bug 83192 has been marked as a duplicate of this bug. ***
correct me if I'm wrong but, we have here the most visible and most ugly bug in
this software. We have a patch wich corrects this bug. We have some people that
testet this patch and all seems okay.

And the only thing that prevents us from not having this problem anymore which
shows on (give me a number) 20% of all webpages out there and makes even desgin
of new pages difficult is that theres nobody who dares to say "yeah this simply
works" and give his r= ??

I would say, yeah let Mozilla crash twice a day if you want cause it is
rockstable nowadays and this doesn't hurt so much but please fix this bug whose
votes and dups are going through the roof...

a user
I applied patch from 38273 and built under Windows NT, got the proper 
transparent animated gif.

r=dbradley for 38273
Whiteboard: top limbo candidate, possible rtm stopper, needs s=, sr= → top limbo candidate, possible rtm stopper, r=bradley, needs sr=
OS: All → Windows NT
Hardware: All → PC
Whiteboard: top limbo candidate, possible rtm stopper, r=bradley, needs sr= → top limbo candidate, possible rtm stopper, r=bradley, needs sr=, a=
I tried this on Win2K and it did *not* fix any of the test cases I tried in this
bug. Perhaps I made and error in the patch application, so I will double check
and try again. Should I see all the test cases in this bug fixed or only certain
ones?
The URL over summary and the first two testcases are 100% cured. The last
testcase has some abnormalities in the upper part but the transparency is OK. I
did not go over all 23 dups but the first 10 are OK. Some of them are actually
dups of bug 83726 which also (and its 6 ot 7 dups) are fixed now. 

The exception id the "XP bug testcase". I suspect it may be a different problem.
Certainly it is not caused by the 4/26 regression which triggered this bug. 
Saari: I forgot to add that my #1 testcase, the big animated GIF in
http://www.hamsterrepublic.com is also fine. If this one does not work for you,
I really doubt you have installed the patch.  
Okay, looks like my frist attempt at patching did in fact fail (big mofo patch),
sorry about that. But yes, I've seen it work now, so r=saari.
Whiteboard: top limbo candidate, possible rtm stopper, r=bradley, needs sr=, a= → top limbo candidate, possible rtm stopper, r=bradley & r=saari needs sr=, a=
sr=roc+moz

Mail to tor@cs.brown.edu and cc drivers@mozilla.org to get approval for checkin.
Thanks for a=. I emailed the approval request as I feel responsible for this bug
by now. I hope I haven't stepped on anyone's toes :-)
a=dbaron for trunk checkin (on behalf of drivers)
Now we only need someone with the right permission to check patch 38273 in...
Whiteboard: top limbo candidate, possible rtm stopper, r=bradley & r=saari needs sr=, a= → top limbo candidate, possible rtm stopper, r=bradley & r=saari, sr=roc+moz, a=dbaron
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 83726 has been marked as a duplicate of this bug. ***
Verifying for WindowsME (CVS Win32 build after patch 38273). I duped the
non-animaded transparent GIF bug 83716 as it is also fixed by the patch.

I believe the remaining (mostly Linux) problems should be filed as a separate
bug or bug 73978 should be reopened - the problems are probably leftovers from
that Linux bug. This bug was created specifically for the Windows regression
repaired by patch 38273. I would not morph it into a general GIF transparecy
problem bug. However, it should be noted that one testcase (the "XP bug") seems
to be a manifestation of a different problem, not the 4/26 regression.
Status: RESOLVED → VERIFIED
Sure. Let's leave this bug for what it fixed, and treat things not fixed as 
distinct issues. I've filed bug 86342 for the 3rd attachment to this bug, which 
is not fixed by the patch for this bug.
John: As you state in the new bug comment the third testcase is not even a
transparent GIF. This means it never had a place in this bug.

Thanks to Timeless for very quickly turning my remarks into a very elegant
patch, and to the reviewers, superreviewers and drivers. 

And sorry for the spam :-)
*** Bug 80199 has been marked as a duplicate of this bug. ***
I just created attachment 06 [details]/20/01 3:11
This bug was supposed to have been fixed, but it is the closest in description
to what I could find. Can this bug be reopened?

My picture is transparent and animated GIF and all of the transparent parts show
up as black, in all of the frames I can make out.
Testcase 39299 WFM
Build-id: 2001061720
OS: Win98
WFM also on Win98.
Ovvldc..   what build and OS are you using?
Testcase 39299 works for me

Build ID: 2001061804 
Windows NT Version 4.0 ( Build 1381: Service pack 4)
The new testcase WFM with WindowsME 2001062004 installator build. I even tried
changing my default background to something other than white but could not see
the problem. 
I'm still seeing a problem with this. On my system the transparency does not 
load until the GIF animation has completed one full loop. Until that time, 
where there should be transparency, the GIF is displayed with plane white. Is 
this a new bug or is it related to this one?
You may see bug 78114. If not, please open a new bug. Your problem is certainly
not this bug as you white background. Read the summary. 
*** Bug 87015 has been marked as a duplicate of this bug. ***
wdormann, sorry I forgot.

I'm using build 20001060703 (win32 talkback installer release 0.9.1) on NT4
(build 1381, SP6).
That should be build 2001060703, of course.

I thought this was fixed before the 9.1 branch so that's why I filed a testcase.
I was out for almost three weeks and didn't follow developments closely. If you
get WFM for current builds, I will be quietly waiting for the 092 release to see
my GIFs animating against a clear background again :).

I am using Build 2001062014 on Win98 and I am still seeing this bug.  Every
animated transparent gif has a black background.
Hmm, this problem looked fixed, then I ran into this: the animated counter on
http://sumomo.sakura.ne.jp/~erika/ seems okay for a couple of frames, and then
parts of it turn black.  Build 2001062104, Win98.
I'm using 2001062004 on Win98 and this bug seems fixed to me. Transparent
backgrounds in animated GIFs do work.

btw. sorry for my last comment on this bug. I shoudn't have been so unpatient to
offend the people that give me a great browsing experience for over a year now
when I gave nothing back :(
Warner Young

The problem you report at "Angel Garden" site is bug 22607
Daniel, thanks.  I'd overlooked that one.
OK, I am using build 2001062204 now on win98, and this bug is gone.  Transparent
backgrounds are transparent.
I'm not sure that this is entirely fixed yet.  I am using build 2001062218 on a
Windows 2000 machine, and I still see some problems with certain animated GIFs.
 For example, the image located at
"http://cgi.resourceindex.com/ads/images/wwm/wwm7.gif" has problems with the
black text when it first displays, in that some of the text has white blotches
in it.  After the first animation loop, the blotches disappear and the image
appears normal.  Other browsers do not have this problem with this image.  I
believe that this report should go here.  If not, please let me know, and I will
file a new bug report for this.  Thanks.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
That may be bug 22607

This bug is for the issue of having a black background on animated GIFs, which
isn't happening with your URL.

back to -> FIXED
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Marking verified since nothing has changed, and this bug was already marked
verified. Please file a new bug if you see behavior which causes your animated
Gifs to appear corrupted. this bug is much to long already.
Status: RESOLVED → VERIFIED
*** Bug 88253 has been marked as a duplicate of this bug. ***
Keywords: qawanted
is bug 85595 related to this?
You need to log in before you can comment on or make changes to this bug.