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

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 http://crrev.com/1767063003, you can run "identify -verbose full2loop.gif | grep 'Iterations'" to check this.

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 https://bugzilla.mozilla.org/show_bug.cgi?id=222176 .  On the bug at the time (see https://bugzilla.mozilla.org/show_bug.cgi?id=222176#c13 ), 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 https://bugzilla.mozilla.org/show_bug.cgi?id=222176 , 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.

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 (https://www.w3.org/Graphics/GIF/spec-gif89a.txt).
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: http://www.vurdalakov.net/misc/gif/netscape-looping-application-extension

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

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.

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.

Deleted: full-loop-gif-image-sequence.png 5.3 KB

	full-loop-gif-image-sequence.png 5.3 KB View Download

Firefox bug: https://bugs.chromium.org/p/chromium/issues/detail?id=592735#c5
Chrome patch to match WebP behavior with GIF: http://crrev.com/1780463007

You provided the wrong link for the Firefox bug.

Oops. Corrected link to FF bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1255497

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/77ed91ec5600ab1331c2faafc1c245a2d33b28a5

commit 77ed91ec5600ab1331c2faafc1c245a2d33b28a5
Author: Urvang Joshi <urvang@google.com>
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 
R=noel@chromium.org, pkasting@chromium.org

Review URL: https://codereview.chromium.org/1767063003 .

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

[add] https://crrev.com/77ed91ec5600ab1331c2faafc1c245a2d33b28a5/third_party/WebKit/LayoutTests/fast/images/resources/full2loop.gif

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a45163dc68252ce3f1958ab58b06a765e652eb70

commit a45163dc68252ce3f1958ab58b06a765e652eb70
Author: urvang <urvang@chromium.org>
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: https://codereview.chromium.org/1769343002

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

[modify] https://crrev.com/a45163dc68252ce3f1958ab58b06a765e652eb70/third_party/WebKit/Source/platform/graphics/BitmapImageTest.cpp
[modify] https://crrev.com/a45163dc68252ce3f1958ab58b06a765e652eb70/third_party/WebKit/Source/platform/image-decoders/gif/GIFImageDecoderTest.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7b7ed0e2c9ce2de3f23102d1eb4c9625a9d73f30

commit 7b7ed0e2c9ce2de3f23102d1eb4c9625a9d73f30
Author: urvang <urvang@chromium.org>
Date: Sat Mar 12 04:44:58 2016

WebP animation: Loop once more than stored loop count.

This is to match existing behavior for GIF in Chrome and other browsers.

BUG= 592735 

Review URL: https://codereview.chromium.org/1780463007

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

[modify] https://crrev.com/7b7ed0e2c9ce2de3f23102d1eb4c9625a9d73f30/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoder.cpp
[modify] https://crrev.com/7b7ed0e2c9ce2de3f23102d1eb4c9625a9d73f30/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoderTest.cpp

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.

After webp animation loop once more than stored loop count,

there is no way to play only once,

how to solve this?

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

https://developers.google.com/speed/webp/docs/webpmux

loop option default value is 0,

if you didn't set loop,

WebP animation will loop infinite.

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.

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:(

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.

any update?

Blocked on webp https://bugs.chromium.org/p/webp/issues/detail?id=309

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

Further tracking should be in https://bugs.chromium.org/p/chromium/issues/detail?id=649264