Closed Bug 522155 Opened 15 years ago Closed 15 years ago

bad animated GIF handle

Categories

(Core :: Graphics, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: Eeems, Assigned: alfredkayser)

References

()

Details

(Keywords: regression, Whiteboard: depends on 519589?)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091013 Minefield/3.7a1pre (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091013 Minefield/3.7a1pre (.NET CLR 3.5.30729) Animated GIF's are not handled correctly A ghost of the previous frames are left behind Reproducible: Always Steps to Reproduce: 1.open any page with animated GIFS Actual Results: The GIF's first frame displayed correctly but any frame afterwords was full of garbage left behind by other frames Expected Results: it should have correctly displayed the animated GIF and there should be no garbage left behind from previous frames
I don't see any issue. Please try in a new profile. In the link you gave, there is some shadowing, but it looks like it is meant to be there, for some reason. I went to several other anigifs, and did not see that.
well I get it on any page I go on...there shouldn't actually be any shadowing on that page, due to the fact that they are all black and white...it might be a profile issue, so I'll test that
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091013 Minefield/3.7a1pre I can indeed reproduce the described behavior. It works fine with Firefox 2 but not with Firefox 3.0 and later. Works: 2007110713 Fails: 2007110719 http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2007-11-07+11%3A00&maxdate=2007-11-07+20%3A00 so Bug 143046 seems a safe culprit to blame, so I'm sure mr Alfred Kayser can tell you more about it.
Blocks: slowGIF
Status: UNCONFIRMED → NEW
Component: General → Graphics
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → thebes
Version: unspecified → Trunk
Confirmed from here. This will require some heavy debugging with the gif code...
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
How can this bug, a regression from 2007, be a duplicate of a bug that regressed last month?
Reopening until clarified. If you mean it will be fixed by the same patch then a "depends on" relation is better so it can be independently verified.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee: nobody → alfredkayser
Whiteboard: depends on 519589?
Keywords: regression
It looks like there has been a fix between Firefox 3.5 and latest trunk and it broke once more. The problem looks very much the same. Same shadows etc.
Depends on: 519589
Might want to check with Bholley and JDrew since decode-on-draw landed some code.
The patch for bug 519589 does fix this problem, so hold off any more analysis until verification.
Fixed by the patch for bug 519589, and verified by testing the imaged referred to above. Nathaniel, can you please test and verify that it is now working as it should?
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
(In reply to comment #11) > Fixed by the patch for bug 519589, and verified by testing the imaged referred > to above. > > Nathaniel, can you please test and verify that it is now working as it should? Did this ever happen?
You need to log in before you can comment on or make changes to this bug.