New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Oct 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Issue 592735: GIF animation loops once more than it should

Reported by, Mar 7 2016 Project Member

Issue description

Version: 48.0.2564.116
OS: Linux

What steps will reproduce the problem?
(1) Open the attached GIF image in Chrome

What is the expected output? What do you see instead?

The loop_count stored in the file is 2, so it should loop 2 times; but animation loops 3 times.

Refer to this info on loop count:

Also, Firefox has the correct behavior (animation loops 2 times).

Comment 1 by, Mar 8 2016


Comment 2 by, Mar 8 2016

648 bytes View Download

Comment 3 by, Mar 8 2016

IE-11 appears to loop 3 times.  Did you test Safari?  On matters of GIF loop count, Peter might be the best reviewer.

Comment 4 by, Mar 8 2016

I'll test on Safari on mac later today.

Meanwhile, as far as ImageMagick goes, it agrees that the loop count is 2. As mentioned in this patch, you can run "identify -verbose full2loop.gif | grep 'Iterations'" to check this.

Comment 5 by, Mar 8 2016

This issue has been contentious over the years.  The disagreement is about how to read the word "loop":

For loop count n,
(a) Decode and display the image normally, then loop it again n times
(b) Decode and display the image for a total of n loops

Another argument is about the display-exactly-once case.  Proponents of (b) argue that (a) makes no sense because it contains no provision for displaying exactly once.  Proponents of (a) argue that that's the normal case without the loop count extension block, and there's no reason to add such a block to your GIF just to say that you want to do the same thing you would have done anyway.

IE and Edge match Chromium.  I don't have a Mac to test Safari, but I'll bet it matches Chromium.  At least on Win 10, the Windows photo app (the closest thing to a "native viewer" I can find) also matches Chromium.

Historically, Firefox also matched this behavior.  They changed this in .  On the bug at the time (see ), it was argued that Opera, Chrome, and "Windows internal image viewer" had the behavior you want.  I am a bit skeptical of this; I believe at the time Chrome and Safari set the current behavior as default it matched IE and Firefox.  The bug claims that "JASC Animation Shop" at the time expected browsers to behave like current Chromium; I haven't tested any image creation tools to see what the case is today.

Assuming Safari does match Chromium, I believe the right thing to do here is to file a bug against Firefox requesting they revert the change from , and linking to this bug or restating the arguments made here.  The other route is to try to get consensus from Microsoft and Apple that it makes sense for everyone to change this.

In a perfect world, I think spec interpretation (b) is more compelling.  However, I'm concerned with web compat issues if most browsers have done (a) for years.

Comment 6 by, Mar 8 2016

I see. Thanks for all the context Peter. I think what makes this contentious is that loop count is an "Application extension", so it's not really part of the GIF spec (
And I couldn't find an official documentation for the Netscape loop count extension. In fact, top web search links and other GIF related pages seem to point to this unofficial documentation:

Let me check the behavior on Safari later today, when I have a Mac with me. And we can decide how to proceed.

Comment 7 by, Mar 9 2016

I tested Safari: it seems to loop the animation 3 times as well (matching current behavior of Chromium and IE/Edge you guys reported).

So, as Peter suggested, I think best course of action is to (1) file a bug against Firefox to match other browsers for GIF and (2) Match behavior of animated WebP with GIF on Chromium.

So, unless someone speaks up otherwise, I'll go ahead with that.

Comment 8 by, Mar 10 2016

A view of the test image (full2loop.gif) that shows what frames are within it ... (attached).

And confirm, viewing in Safari 9.0.3, the yellow frame is shown three times.

So yeap, there's a browser compat issue to resolve (file a Firefox bug), and webp animated needs to align with the rest of the GIF world.  Sounds like a plan.
5.3 KB View Download

Comment 9 by, Mar 10 2016

Firefox bug:
Chrome patch to match WebP behavior with GIF:

Comment 10 by, Mar 10 2016

You provided the wrong link for the Firefox bug.

Comment 11 by, Mar 10 2016

Comment 12 by, Mar 11 2016

Project Member
The following revision refers to this bug:

commit 77ed91ec5600ab1331c2faafc1c245a2d33b28a5
Author: Urvang Joshi <>
Date: Fri Mar 11 01:16:08 2016

Add a GIF test file to test loop count behavior

This file has a loop count of 2, which can be verified by running:
"identify -verbose full2loop.gif | grep 'Iterations'"

This test file will be used in a unit test in the next patch.

BUG= 592735,

Review URL: .

Cr-Commit-Position: refs/heads/master@{#380505}


Comment 13 by, Mar 12 2016

Project Member
The following revision refers to this bug:

commit a45163dc68252ce3f1958ab58b06a765e652eb70
Author: urvang <>
Date: Sat Mar 12 00:22:28 2016

GIF decoding: Add a unit test for repetition count

Also add a test to BitmapImageTest to ensure we loop one
extra time when animating.

BUG= 592735 

Review URL:

Cr-Commit-Position: refs/heads/master@{#380800}


Comment 14 by, Mar 12 2016

Project Member

Comment 15 by, Mar 14 2016

Status: Fixed (was: Assigned)
This is done now:
- GIF behavior turned out to be consistent with other browsers, so just added tests for current behavior.
- Changed WebP animation to behave similar to GIF.
- Filed a firefox bug so that they match Chromium and other browsers.

Comment 16 by, Sep 7 2016

After webp animation loop once more than stored loop count,

there is no way to play only once,

how to solve this?

Comment 17 by, Sep 7 2016

Don't have a loop count at all?  That's how you make a play-once GIF.

Comment 18 by, Sep 8 2016

loop option default value is 0,

if you didn't set loop,

WebP animation will loop infinite.

Comment 19 by, Sep 8 2016

Not setting a -loop value at all ought to not write a loop count into the file, at which point the browser should treat it as non-looping.  If this isn't the case, I consider it either a bug in webpmux or the WebP format itself, as the goal of the change in comment 14 was to harmonize WebP with GIF, and that's how GIF does non-looping animations.

Neither of those would be a Chrome bug, though, and I'm not the WebP format expert.

Comment 20 by, Sep 8 2016

Is any chance to revert comment 14?

although that will cause webp and gif behavior not harmonize, but it's can play webp animation only once at least.

It's no way to play webp once on current version:(

Comment 21 by, Sep 8 2016

Urvang would have to comment on whether there is, in fact, some way to do what you want.

I agree that we don't want to be in a situation where there's truly no way to make a play-once .webp.

Comment 22 by, Sep 15 2016

any update?

Comment 23 by, Oct 13 2016

Status: Started (was: Fixed)
Blocked on webp

I'll try to get their attention on this issue.

Comment 24 by, Oct 13 2016

Status: Fixed (was: Started)

Comment 25 by, Oct 13 2016

Sign in to add a comment