[Webkit-unassigned] [Bug 23684] Endless loop for image with zero duration frame

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Aug 2 15:10:58 PDT 2015


https://bugs.webkit.org/show_bug.cgi?id=23684

Jeremy Zerfas <WebKit at JeremyZerfas.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |WebKit at JeremyZerfas.com

--- Comment #8 from Jeremy Zerfas <WebKit at JeremyZerfas.com> ---
This ticket has been open for several years and I just thought I would point out that although this bug seems to have been valid back then, some of the relevant code has been refactored since then and there is no longer a potential for an endless loop. In the current code, if the containing loop doesn't exit the function, then on each iteration of that loop it instead increments frameAfterNextStartTime by the frameDurationAtIndex() function (which normally never returns a value less than 0.011 seconds) and eventually causes the loop to end.

I'm attaching two GIFs I created that contain zero duration frames in case anyone wants them for testing. Both GIFs contain a repeating animation that shows the numbers 1, 2, and 3 after each other. In "Animated GIF with Single Zero Duration Frame.gif", the first and third frames have a one second delay but the second frame has a zero second delay. In "Animated GIF with All Zero Duration Frames.gif" all the frames have zero second delays.

It looks like zero duration frames are allowed by GIFs and do have some valid uses, see http://www.imagemagick.org/Usage/anim_basics/#zero . Mozilla added some code back in late 2013 to respect those zero duration frames for non-looping GIFs but it looks like they just recently found out that the new code is causing problems with some (poorly made) GIFs on the web and will be removing that code, see https://bugzilla.mozilla.org/show_bug.cgi?id=890743 .

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150802/4ab6feb9/attachment.html>


More information about the webkit-unassigned mailing list