You need to
before you can comment on or make changes to this bug.
The code in PNGImageDecoder.cpp (not used for Safari Mac/Win, but used by Cairo/QT) can throw away data when consumers call any decoding-related functions on it before frameBufferAtIndex().
This is because the libpng code will only decode incoming data once (it remembers it's already decoded the existing data when asked to decode it again), and if no frame buffer is set up when it makes its callbacks, the relevant data is simply discarded. And the frame buffer vector isn't resized to 1 frame (from 0) until frameBufferAtIndex() is called.
I don't see a good reason for this. A single frame buffer entry takes up almost no memory before the underlying RGBA32Buffer is set up, so there really isn't a penalty for just sizing m_frameBufferCache to 1 in the constructor. This also saves some conditionals in various places that no longer need to worry about whether this vector is empty.
Patch to fix coming shortly.
Created an attachment (id=16138) [details]
With this patch, consumers can call any function on the PNGImageDecoder and trust that the image data won't be discarded.
(From update of attachment 16138 [details])
Landed in r25294.