Does passing --disable-features=CompositorImageAnimation on the command line change (fix) the behavior?

I can repro this with that feature enabled and not without it.

https://chromium-review.googlesource.com/c/chromium/src/+/934968 in review.

M65 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Merge has to happen latest by 4:00 PM PT Monday (02/26/18) in order to make it to last M65 beta release next week. Thank you.

So, this report was helpful?
How long before the stable (ie, general public) version of Chrome is fixed?

Is it worth noting that this bug is also present in Mac Safari?

Gentle ping !!
Please merge fix ASAP as M65 stable promotion is today night as it is marked stable blocker for M65.

Thanks..!

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

commit 644b058c04c5a38e758f07832323f104c12443ad
Author: Khushal <khushalsagar@chromium.org>
Date: Mon Feb 26 19:45:19 2018

images: Fix image animations for images with specific loop count.

For an image with a repetition count of n, it should animate for
n+1 loops. But the compositor only performs n loops. Fix this by
specifying the actual repetition count of PaintImage.

R=chrishtr@chromium.org

Bug:  815038 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I450d435ed38a3beba30276fa4dbabdcb5a68a944
Reviewed-on: https://chromium-review.googlesource.com/934968
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539238}
[add] https://crrev.com/644b058c04c5a38e758f07832323f104c12443ad/third_party/WebKit/LayoutTests/images/resources/three-frames_loop-three-times.gif
[modify] https://crrev.com/644b058c04c5a38e758f07832323f104c12443ad/third_party/WebKit/Source/platform/graphics/BitmapImage.cpp
[modify] https://crrev.com/644b058c04c5a38e758f07832323f104c12443ad/third_party/WebKit/Source/platform/graphics/BitmapImageTest.cpp

Requesting merge. I'll wait to ensure that it is fixed in tomorrow's canary before merging.

Re #7, this will be fixed in the next release, which should be out in another 2 weeks. Please file a bug for the same error on safari.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re: Comment #8
That actually is quite important. But mostly just for awareness.

The gif format has an official specification. Then there is more of a street spec that the major browsers follow.
For example, if a palette is 64 colors and the frame attempts to use palette index 100, the official spec says this image is malformed. However, the major browsers allow out-of-palette indices to be used for the transparent index. So if palette index 100 is the transparent index, we would treat it as a valid file and a valid palette entry.

Before compositor image animation, we would have shown 3 loops. So the fix keeps Chrome consistent with its old behavior. It is also consistent with FireFox and Edge.

The fact that Safari behaves differently just means the street spec isn't well established. :) We should probably write down the ways we deviate from the official spec at some point.

Thanks for the insight cblume@chromium.org.

With the historical browser implementations and the likes of Adobe Photoshop also using a "play through + addition loop count = total sequences" calculation, I'd have thought the "street spec" was well established.
Does Safari/Webkit borrow from the Chrome code base (or the reverse), leading to both being flawed lately?

ps (We have confirmed the bug exists on Safari desktop and iOS versions.)

Safari and chrome don't share any rendering code. The bug in chrome is from a new feature roll out which is why it regressed. Its worth checking whether the safari behaviour is new or has always been this way.

 khushalsagar@, pls update bug with canary result tomorrow. Thank you.

Tested this issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the reported version 64.0.3282.167 and latest Canary 66.0.3356.0 by following the steps mentioned in the original comment.
Able to reproduce this issue on the reported version 64.0.3282.167 and the issue is fixed on the latest Canary 66.0.3356.0.

On loading the gif animation, the looping is done for 3 times on the latest Canary build.
Attached is the screen cast for reference.

Hence adding TE verified labels as the fix is working as intended.

Thanks..

Deleted: 815038-CL.mp4 395 KB

	815038-CL.mp4 395 KB View Download

The NextAction date has arrived: 2018-02-27

Verified that the fix works for canary. The change is safe to merge, its constricted only to this bug. Requesting merge.

Approving merge to M65 branch 3325 based on comments #17 & #19. Please merge ASAP. And mark the bug as fixed after the merge if nothing is pending. Thank you.

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

commit a5d4de2183243b3c6d22e587137c60c9976d39fc
Author: Khushal <khushalsagar@chromium.org>
Date: Tue Feb 27 17:17:06 2018

images: Fix image animations for images with specific loop count.

For an image with a repetition count of n, it should animate for
n+1 loops. But the compositor only performs n loops. Fix this by
specifying the actual repetition count of PaintImage.

R=chrishtr@chromium.org
TBR=khushalsagar@chromium.org

(cherry picked from commit 644b058c04c5a38e758f07832323f104c12443ad)

Bug:  815038 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I450d435ed38a3beba30276fa4dbabdcb5a68a944
Reviewed-on: https://chromium-review.googlesource.com/934968
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#539238}
Reviewed-on: https://chromium-review.googlesource.com/939529
Reviewed-by: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#606}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[add] https://crrev.com/a5d4de2183243b3c6d22e587137c60c9976d39fc/third_party/WebKit/LayoutTests/images/resources/three-frames_loop-three-times.gif
[modify] https://crrev.com/a5d4de2183243b3c6d22e587137c60c9976d39fc/third_party/WebKit/Source/platform/graphics/BitmapImage.cpp
[modify] https://crrev.com/a5d4de2183243b3c6d22e587137c60c9976d39fc/third_party/WebKit/Source/platform/graphics/BitmapImageTest.cpp