Transparent animating GIFs have black background

VERIFIED FIXED in mozilla0.9.3



17 years ago
10 years ago


(Reporter: Jeff Anonymous, Assigned: saari (gone))


(4 keywords)

Windows NT
helpwanted, regression, testcase, top100

Firefox Tracking Flags

(Not tracked)


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


(8 attachments)



17 years ago
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.


17 years ago
Keywords: nsCatFood


17 years ago
Keywords: verifyme

Comment 1

17 years ago
I am seeing this with build 2001-04-27-09-ttunk w2k, also see that 
still has an animating image problem as well :-(
Ever confirmed: true

Comment 2

17 years ago
I believe you mean the solution to bug 73978.

Comment 3

17 years ago
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 ?

Comment 4

17 years ago
You are right. I installed 2001042604 to check this. Yesterday build had bug
73978 fixed but not yet this bug.

Comment 5

17 years ago
I'm seeing this with 2001042713 (0.9 branch) on Linux. I suggest changing
Platform/OS to All/All

Comment 6

17 years ago
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


Comment 7

17 years ago
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

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.

Comment 8

17 years ago
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).

Comment 9

17 years ago
On 2001043004 Win2k trunk, GIFs that are used as UL graphics suffer the same
problem - see

Is this the same bug or should I file a new one?

Comment 10

17 years ago
still a problem on 5/2 trunk builds...

this affects sidebar, we get a black square for the "loading icon"

Comment 11

17 years ago
*** Bug 79015 has been marked as a duplicate of this bug. ***


17 years ago
Keywords: verifyme
OS: Windows 98 → All
Hardware: PC → All

Comment 12

17 years ago
*** Bug 79138 has been marked as a duplicate of this bug. ***

Comment 13

17 years ago
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

Comment 14

17 years ago
Setting top100 keyword.
Keywords: top100

Comment 15

17 years ago
*** Bug 79399 has been marked as a duplicate of this bug. ***

Comment 16

17 years ago
*** Bug 79440 has been marked as a duplicate of this bug. ***

Comment 17

17 years ago
*** Bug 79489 has been marked as a duplicate of this bug. ***

Comment 18

17 years ago
This seems similar to a bug I am seeing on, 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.

Comment 19

17 years ago
*** Bug 79703 has been marked as a duplicate of this bug. ***
*** Bug 80441 has been marked as a duplicate of this bug. ***
Bug 78733 is similar.
*** Bug 80409 has been marked as a duplicate of this bug. ***

Comment 23

17 years ago
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. ***

Comment 25

17 years ago
saari, isn't this fixed?
Assignee: pavlov → saari
I still see this with 2001-05-16-04, Win NT.

Comment 27

17 years ago
strange happening ... at ... just move the 
mouse over one rectangle, the transparent animating gif has a white background!

seen with build 2001051604 on win2k

Comment 28

17 years ago
The loading.gif shows up black in the sidebar and ftp loading on windows.
it works on the mac.


17 years ago
Blocks: 81552

Comment 29

17 years ago
*** Bug 81954 has been marked as a duplicate of this bug. ***

Comment 30

17 years ago
High priority for 0.9.2
Priority: -- → P1
Target Milestone: --- → mozilla0.9.2
Any idea when this will get fixed ?

Comment 32

17 years ago
Probably next week barring unforseen things

Comment 33

17 years ago
*** Bug 82934 has been marked as a duplicate of this bug. ***

Comment 34

17 years ago
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 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.

Comment 35

17 years ago
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?

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.

Comment 36

17 years ago
*** Bug 83361 has been marked as a duplicate of this bug. ***

Comment 37

17 years ago

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.

Comment 38

17 years ago
Keywords: nsbeta1

Comment 39

17 years ago
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. 
Is the win32 bug
Is the XP GIF animation bug

Comment 40

17 years ago
*** Bug 83563 has been marked as a duplicate of this bug. ***

Comment 41

17 years ago
*** Bug 83562 has been marked as a duplicate of this bug. ***


17 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 42

17 years ago
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.

Comment 43

17 years ago
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.

Comment 46

17 years ago
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.

Comment 47

17 years ago
For those that don't keep up with Mozilla development.. it originated with the
landing of imglib2 (libpr0n).

Comment 48

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

Comment 49

17 years ago
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

Comment 50

17 years ago
Jacek is correct. This bug was fixed for about 1 day immediately after bug 73978
was fixed, then it regressed.

Comment 51

17 years ago
*** Bug 78114 has been marked as a duplicate of this bug. ***
*** Bug 83893 has been marked as a duplicate of this bug. ***

Comment 53

17 years ago
No change, still there in:
build id 2001-06-02-20 trunk windows zipped


Comment 54

17 years ago
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?

Comment 55

17 years ago
It's still nsbeta1, Netscape knows better than to let something like this get
into anything even remotely public.

Of course, AOL doesn't...

Comment 56

17 years ago
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.

Comment 58

17 years ago
can we get status on this? sidebar loading icon is affected by this...

Comment 59

17 years ago
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.

Comment 60

17 years ago
Created attachment 37417 [details]
Transparent animated GIF testcase


17 years ago
Keywords: testcase

Comment 61

17 years ago
*** Bug 84370 has been marked as a duplicate of this bug. ***

Comment 62

17 years ago
Created attachment 37522 [details]
very slow animating GIF testcase

Comment 63

17 years ago
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?)

Comment 64

17 years ago
Well, with 2001060504 on win2k, I don't see any noise pixels on your attachement...

Comment 65

17 years ago
Older builds did do that.. now its just black.. Win2K/2001060620trunk

Comment 66

17 years ago
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*

Comment 67

17 years ago
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.

Comment 68

17 years ago
*reads bug 82868* ... nothing in any of the comments on that bug even remotely
resemble what I described.

Comment 69

17 years ago
I can confirm'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).

Comment 70

17 years ago
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). 

Comment 71

17 years ago
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 
i'm using win ME, build 201052404.

also the first image, loaded correctly with no artifacting which i had on the 
attached image.

Comment 72

17 years ago
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. 

Comment 73

17 years ago
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...

Comment 74

17 years ago
Also note that the Modern theme throbber is affected by this bug (though it
should probably just be replaced with the Classic theme throbber..)

Comment 75

17 years ago
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 ?

Comment 77

17 years ago
*** Bug 84898 has been marked as a duplicate of this bug. ***

Comment 78

17 years ago
I've got 2001060811 and I see no problems with either of the testcase
attachments above. This in on RedHat Linux 7.1.

Comment 79

17 years ago
I still see this bug on build 2001060920 (PC, WinME)

Comment 80

17 years ago
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

Comment 81

17 years ago
Created attachment 37874 [details]
XP bug testcase

Comment 82

17 years ago
Created attachment 37882 [details]
bonus GIF possibly handled incorrectly

Comment 83

17 years ago
"While we're at it", I have attached an animated GIF which is
problematic in another way.

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.

Comment 84

17 years ago
*** Bug 85177 has been marked as a duplicate of this bug. ***

Comment 85

17 years ago
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

Comment 86

17 years ago
Here are a couple more sites which exhibit this bug: (Your Shopping Cart image and 1-Rate Shipping /
Save Money images) (most of the images on the front page)

Comment 87

17 years ago
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. 

Comment 88

17 years ago
This bug was fixed for a day, untill timeless checked in the following one line

--- 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.


Comment 89

17 years ago shows this bug too.

Comment 90

17 years ago
that's an interesting arguement except that my patch was never committed.
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.

Comment 91

17 years ago
*** Bug 85275 has been marked as a duplicate of this bug. ***

Comment 92

17 years ago
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...

Comment 93

17 years ago
Is this bug being looked at? Seems pretty bad to me.

Comment 94

17 years ago
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. 

Comment 95

17 years ago
I added to the CC: list as his code created this regression.

Comment 96

17 years ago
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.  

Comment 97

17 years ago
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?

Comment 98

17 years ago
Created attachment 38027 [details] [diff] [review]
rearrange windows leak catching

Comment 99

17 years ago
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 
Keywords: helpwanted, qawanted

Comment 100

17 years ago
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=

Comment 101

17 years ago
Don't know if this is related to this bug, but at
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)

Comment 102

17 years ago
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.

Comment 103

17 years ago
*** Bug 85368 has been marked as a duplicate of this bug. ***

Comment 104

17 years ago
Linux has had this bug for quite awhile, but actually in yesterday's builds it
seemed ok...

Comment 105

17 years ago
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:

Comment 106

17 years ago
*** Bug 85642 has been marked as a duplicate of this bug. ***

Comment 107

17 years ago
Created attachment 38273 [details] [diff] [review]
based on Jacek Piskozub's advice

Comment 108

17 years ago
ok, so we have a regression caused by a bad leak fix by dprice r=pavlov 

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

Comment 109

17 years ago
*** Bug 84719 has been marked as a duplicate of this bug. ***

Comment 110

17 years ago
The renown germany computer magazin CHIP is complaining about this bug ...

Do hope to get this one into 0.9.2

Comment 111

17 years ago
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 :-)

Comment 112

17 years ago - this one looks as a garbage
with this bug... defenetly a 0.9.2 bug

Comment 113

17 years ago
The patch does not seem to fix the problem for me

Comment 114

17 years ago
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.

Comment 115

17 years ago
Errr... Correction. I mean bug 83726 :-(

Comment 116

17 years ago
*** Bug 83788 has been marked as a duplicate of this bug. ***

Comment 117

17 years ago
W2K build 2001061404 still shows this bug.
Another example:

Comment 118

17 years ago
*** Bug 83192 has been marked as a duplicate of this bug. ***

Comment 119

17 years ago
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

Comment 120

17 years ago
I applied patch from 38273 and built under Windows NT, got the proper 
transparent animated gif.

r=dbradley for 38273


17 years ago
Whiteboard: top limbo candidate, possible rtm stopper, needs s=, sr= → top limbo candidate, possible rtm stopper, r=bradley, needs sr=


17 years ago
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=

Comment 121

17 years ago
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

Comment 122

17 years ago
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. 

Comment 123

17 years ago
Saari: I forgot to add that my #1 testcase, the big animated GIF in is also fine. If this one does not work for you,
I really doubt you have installed the patch.  

Comment 124

17 years ago
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.


17 years ago
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=

Mail to and cc to get approval for checkin.

Comment 126

17 years ago
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)

Comment 128

17 years ago
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

Comment 129

17 years ago
Fix checked in.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 130

17 years ago
*** Bug 83726 has been marked as a duplicate of this bug. ***

Comment 131

17 years ago
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.

Comment 132

17 years ago
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.

Comment 133

17 years ago
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 :-)

Comment 134

17 years ago
*** Bug 80199 has been marked as a duplicate of this bug. ***

Comment 135

17 years ago
Created attachment 39299 [details]
Rotating @ sign, background shows all black

Comment 136

17 years ago
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.

Comment 137

17 years ago
Testcase 39299 WFM
Build-id: 2001061720
OS: Win98

Comment 138

17 years ago
WFM also on Win98.
Ovvldc..   what build and OS are you using?

Comment 139

17 years ago
Testcase 39299 works for me

Build ID: 2001061804 
Windows NT Version 4.0 ( Build 1381: Service pack 4)

Comment 140

17 years ago
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. 

Comment 141

17 years ago
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?

Comment 142

17 years ago
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. 

Comment 143

17 years ago
Created attachment 39424 [details]
partially fixed on Win98 build 2001061804, but still broken on "Authoritarian"

Comment 144

17 years ago
*** Bug 87015 has been marked as a duplicate of this bug. ***

Comment 145

17 years ago
wdormann, sorry I forgot.

I'm using build 20001060703 (win32 talkback installer release 0.9.1) on NT4
(build 1381, SP6).

Comment 146

17 years ago
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 :).

Comment 147

17 years ago
I am using Build 2001062014 on Win98 and I am still seeing this bug.  Every
animated transparent gif has a black background.

Comment 148

17 years ago
Hmm, this problem looked fixed, then I ran into this: the animated counter on seems okay for a couple of frames, and then
parts of it turn black.  Build 2001062104, Win98.

Comment 149

17 years ago
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

Comment 151

17 years ago
Daniel, thanks.  I'd overlooked that one.

Comment 152

17 years ago
OK, I am using build 2001062204 now on win98, and this bug is gone.  Transparent
backgrounds are transparent.

Comment 153

17 years ago
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
"" 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.
Resolution: FIXED → ---

Comment 154

17 years ago
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
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 155

17 years ago
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.

Comment 156

17 years ago
*** Bug 88253 has been marked as a duplicate of this bug. ***


17 years ago
Keywords: qawanted

Comment 157

17 years ago
is bug 85595 related to this?
You need to log in before you can comment on or make changes to this bug.