Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 437662 Support for Animated PNG
Starred by 848 users Reported by, Nov 30 2014 Back to list
Status: Assigned
Merged: issue 1171
EstimatedDays: ----
NextAction: 2017-03-02
OS: Linux, Android, Windows, Chrome, Mac
Pri: 2
Type: Launch-OWP
Launch-Accessibility: NA
Launch-Legal: Yes
Launch-M-Approved: ----
Launch-M-Target: 59-Dev, 59-Beta, 59-Stable-Exp, 59-Stable
Launch-Privacy: NA
Launch-Security: Yes
Launch-Status: Review-Requested
Launch-Test: ----
Launch-UI: NA

Blocked on: View detail
issue 704425
issue 698487
issue 698490

issue 698808
issue 699675
issue 700892

Hotlists containing this issue:

Sign in to add a comment
Change description:
Implement APNG (Animated PNG) support

Changes to API surface:

CrBug feature request (lots of stars):
APNG Test Suite:
More tests:

Support in other browsers:
Internet Explorer: No
Firefox: Yes
Safari: Yes
Comment 1 by, Apr 13 2015
Mergedinto: 1171
Status: Duplicate
Not really a duplicate of 1171, which was "request for enhancement".

This one is OWP launch tracking bug.

Blink CL:
Comment 3 by, Aug 28 2015
Labels: Cr-Blink-Image
Status: Untriaged
Comment 5 by, Nov 17 2015
Do you it would be good idea to mark this as "No active development" on or is there any serious attempt to do this finnaly?
Comment 6 Deleted
Comment 7 by, Nov 17 2015
To me, "no active development" kinda implies "I give up" which isn't the case at all.

At this point I'm waiting for the Blink team and the Owners to make a decision.
(to clarify: I'm outside contributor, not a googler)

The code is fully functional, that's why you don't see any recent updates. I might update it a little to deal with accumulated bitrot from time to time, but that's it.

There is an "Intent to Implement: Animated PNG" discussion on blink-dev with some additional details on what's going on here.
Comment 8 by, Nov 17 2015
Oh, right, sorry then.
Comment 9 Deleted
Fixed incorrect decoding of ICO files containing PNG data.

new CL:
Some "unsigned" -> "size_t" changes, no big deal.

CL is the same.
Issue 580778 has been merged into this issue.
Comment 13 by, Jan 26 2016
I don't know, but given the revival of the GIF format and animations suddenly appearing everywhere from major news sites to blogs and social networks and so on, I'd think that this feature is a big deal. 

If I were part of the Chromium/Blink upper echelon, I'd want to roll this out as soon as possible or feasible, with all the fanfare.

Make some splash, let them know who supported this first, real money says this could be the next game changer.

At least send a link to this issue to some friends, colleagues and so on, this needs more stars ;-)
Comment 14 by, Jan 26 2016
I guess this feature is not yet implemented because google wants to force everyone to use google's own standards, like Microsoft. Something like GoogIF. For example google offers to save password on sites which asks browser not to do it. 
#14, most GIFs you see on popular sites (such as imgur, gfycat and 9gag) are actually WebMs. That said, Chrome does already support animated WebP:
Imgur only converts long GIFs into video. Short ones are still GIFs. For example:

Google is another somewhat popular site with GIFs on the front page ;)

Comment 17 by, Jan 28 2016
#15, case in point: WebM videos, looped and without sound, just an ugly workaround for better animations.

It can't be more obvious that the demand exists. Sites like gfycat are the living proof.

Animated WebP, APNG/MNG, whatever..

They all beat GIF. We will see what gets adopted first.
Comment 18 Deleted
Chrome Android does not allow autoplay for vidoe tags, so all videos converted from gif can not behave like original gif.
in my Opinion APNG is the best GIF Alternative since it offers everything PNGs do, partial transparency, losslessness while giving it animation.
teamhydr, Fully agree with you. It's smart and easy tool for do Alpha-Animated effects on web. And I'm in sorrow that Chrome still not support it.
Guys, just let's do it!

Is it Microsoft Edge will make support of APNG before the Google Chrome team? :)
Please, dont do vendor formats war!
Just allow us, web developers, do good things.
Updated due to recent changes in original PNGImageDecoder.

Same CL:
Mergedinto: 1171
Status: Duplicate
Comment 24 by, Jul 20 2016
Status: Available
Assigning to myself to pass on to actual implementors.
Status: Assigned
Comment 29 by, Jul 21 2016
Status: Duplicate
Why was this deduped from the original APNG support issue?  Let's just have one tracking bug.
First, this one is created as Launch-OWP bug, to track the actual implementation.
(as described in instructions)

Second, 1171 was closed for comments many years ago.
Updated due to recent Blink Reformat.
Status: Assigned
Issue 1171 has been merged into this issue.
Made this one the true bug, because it does have the launch tracking and that's justified in this case (I think).
So I just find out there is another implementation work is going on... Posting the link here, 

I guess I can stop keeping my implementation up-to-date now, but it's still there:

Not sure about the need to do the same work twice, but OK.
Project Member Comment 36 by, Dec 5
The following revision refers to this bug:

commit 378e8f3d4729d64eacd3ea24bd05f4d1e11502f6
Author: joostouwerling <>
Date: Mon Dec 05 22:50:37 2016

Add a basic test suite for PNGImageDecoder.

Add the following tests for PNGImageDecoder:
- Verify that the repetition count is cAnimationNone.
- Verify that the image size is decoded correctly.
- Verify that the decoded frame count is 1, and that the frame duration
  is 0.
- Verify that progressively providing the image data yields the same
  frame buffer hashes as when the data is provided in a truncated form.
- Verify that progressive decoding can completely decode the image when
  at first half of the image data is provided and the image is partially
  decoded, and then the rest of the image data is provided. It verifies
  that the content of the intermediate and final frame are different.
- Verify that the decoder is invalidated when invalid image data is
- Verify that frameIsCompleteAtIndex() returns true if and only if the
  frame is completely decoded. Fully receiving the image data is not
  enough to be considered complete for static PNGs.

The image that is being tested is a simple 111 by 29 pixels image
created by myself.

As an additional note here - some of these tests are a little awkward when this
CL is viewed in isolation, with e.g. separate functions for tests which allow
more configuration than necessary. This is done so they can be reused for APNG
tests, which is currently in development in


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


Please provide the following information, so that chrome test engineering team can proceed with testing.

1. Is the feature code complete & enabled in the trunk and ready for testing?
2. Does this require manual testing?
3. Any specific setup / flags required?
4. Do we have enough UMA coverage to measure the stability? Its highly recommend always adding Stability.Counts and CrashExitCodes.* to your json to measure stability of your experiment.

Just realized Joost wasn't on this.. will start some answers:
1. code complete, not yet committed as we are trying to verify we have the right test plan in place
2. yes? seems we should have a minimal set of tests to verify animated content correctness
3. no
4. ?
There are discussions ongoing to finalize whether this will be integrated as-is directly or enabled with an accept header value. The feature code itself is not changing though, and we are losing the main developer on it end of week, any possibility we could integrate to a branch or another method of getting some early testing?
Project Member Comment 40 by, Jan 5
The following revision refers to this bug:

commit 1cc893851ef9ad007f4fb1eaabf58870fc634e81
Author: scroggo <>
Date: Thu Jan 05 15:52:12 2017

Add fuzzer for (A)PNG decoder

Implement a fuzzer for the PNG decoder. It uses three animated png images
created by and three existing static PNG images
in WebKits LayoutTest resources as a seed corpus.

It works for both the current PNGImageDecoder, which only supports
decoding static PNGs, and the new PNGImageDecoder which also supports
decoding animated PNGs. This is achieved by having both static and
animated PNG images in the seed corpus.


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


Labels: Launch-Status-Review-Requested
Main (updated) CL with implementation:
Labels: Launch-Security-Started
From a security perspective, the main thing I'd want to see is a fuzzer, and we got that in #40 from scroggo. Thanks, scroggo! +mbarbella: LGTY?
Just don't forget to fix that one bug caught by the fuzzer.

Labels: -Launch-Security-Started Launch-Security-Yes
LGTM overall. It's probably also worth taking a look at the coverage report from to see if there are other potential candidates for files to add to the corpus.

At a glance the numbers look a little low to me, but we tend to link a bit too much into these binaries because of the sanitizer instrumentation. Still, there should be some room for improvement.
hcm@: Just wondering, do we have any high level test plan exists for this feature? so that test engineering team would be able to review this.

Thank you!
We are primarily leaning on automated testing, but there is a request to manually execute this test:
Labels: M-58
NextAction: 2017-03-02
Note this is currently the #4 topped starred Blink bug.

From offline conversation I understand the implementation is pretty good shape ( with some minor details still being ironed out before an intent-to-ship thread.

hcm/scroggo does it seem like M58 (3/2 branch) is a possible launch milestone worth targetting (with the understanding of course that there's always unexpected delays, especially when changing API surface area like this)?  Setting labels for that, but feel free to update.

Labels: Launch-M-Target-58-Dev
Yes, we're targeting M58.
+ajha, who is already looking into this feature testing.
Please apply appropriate OS labels. Thank you.
Labels: OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
candrada@ for test planning on Android.
Comment 54 Deleted
Labels: Launch-Legal-Yes
Project Member Comment 56 by, Feb 9
The following revision refers to this bug:

commit 9f178059a3f0fd6f7a151bfe129a697ceaf0b150
Author: mmoroz <>
Date: Thu Feb 09 14:29:11 2017

Add more as seed corpus for blink_png_decoder_fuzzer.

Add corpus //WebKit/LayoutTests/images/png-suite/samples and

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


I just created APNG animation with google logo (ajax loader). This looks cool for Google Pages.

Please check file attachments
37.1 KB View Download
37.1 KB View Download
Just to update, tested this on Windows-10, latest canary(58.0.3021.0) as per Attached is the screen-cast of the behavior observed with 'Test page with APNG set' and 'Reference page with static PNG files'.

Looks like implementation CL: is still not committed in canary as I am not seeing any animation on 'test1.html' from

hcm@/scroggo@/mmoroz@: Could you please confirm if anything being missed here or this is still in line for M-58(branch 03/02).

Thank you! 
898 KB View Download
Labels: -Launch-M-Target-58-Dev Launch-M-Target-59-Dev
Due to delays in launch process and latest feedback/tweaks being made on the CL, I think we are forced to retarget to 59.  We will work to get this in asap after branch for maximum test time and assurance we get it in the next milestone.
What? Please, add APNG support for 58 dev version. 
Labels: -Type-Launch-OWP Launch-M-Target-59-Beta Launch-M-Target-59-Stable-Exp Launch-M-Target-59-Stable Launch-Privacy-NA Type-Launch
Labels: Launch-Accessibility-NA Launch-UI-NA
Blocking: 698808
govind@, do we need anything here to flip the Launch-Test bit?
+ manoranjanr@, could you please check testing status on Desktop with ajha@.

candrada@, is testing on Android completed?

The actual CL ( yet to be landed in trunk.

hcm@/noel@, do we have any ETA?

Thank you!
We haven't completed testing.  We are planning to test on Android in M59 since it's been moved.
Blocking: 699675
#66 Nope.
Blocking: 700892
Blockedon: 698487
Any reason why this issue is under Restrict-View-Google label?

Blockedon: 698490
> Any reason why this issue is under Restrict-View-Google label?

The comments don't show where the label got added (should they?), and it presumably didn't start that way (since maxstepin@gmail reported the bug). I looked through the dupes and blocks, and none of them are Restrict-View-Google.
Happened fairly recently, around Feb 28/March 1. Probably by accident, other labels have been changed around that time (mostly from 58 to 59).
Normally, yes, comments should show where the RestrictViewGoogle was added.

If you hover the "Restrict View Google" label, it's marked "Derived". My *guess* is that this restriction occurred because in Comment #61, Type went from Type-Launch-OWP to Type-Launch, which results in the view restriction being derived.
Comment 78 by, Mar 20 (6 days ago)
Labels: -Type-Launch Type-Launch-OWP
Type=Launch bugs are intended for internal Google tracking only and so are always RVG, so this was probably an unintended side-effect of the label change in #61.  Since this is a web exposed change developers care about, we should probably be using Launch-OWP instead (or filing a separate Type=Launch bug for the bookkeeping if necessary).
Comment 79 by, Mar 23 (3 days ago)
Blockedon: 704425
Sign in to add a comment