Closed Bug 77914 Opened 24 years ago Closed 23 years ago

Transparent animating GIFs have black background

Categories

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

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: jefftl, Assigned: saari)

References

(
URL
)

Details

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

Attachments

(8 files)

Transparent animated GIF testcase
334 bytes, image/gif
Details
very slow animating GIF testcase
264 bytes, image/gif
Details
XP bug testcase
3.74 KB, image/gif
Details
bonus GIF possibly handled incorrectly
25.83 KB, image/gif
Details
rearrange windows leak catching
1.10 KB, patch
Details | Diff | Splinter Review
based on Jacek Piskozub's advice
31.06 KB, patch
Details | Diff | Splinter Review
Rotating @ sign, background shows all black
15.35 KB, image/gif
Details
partially fixed on Win98 build 2001061804, but still broken on "Authoritarian"
17.50 KB, image/gif
Details
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 ago → 23 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.

Attachment

General

Creator:
Created:
Updated:
Size: