Fix ImageDecoder::frameIsCompleteAtIndex - fully received instead of decoded.

third_party/WebKit/Source/platform/image-decoders/ImageDecoderTestHelpers.cpp

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "platform/image-decoders/ImageDecoderTestHelpers.h"
 
 #include "platform/SharedBuffer.h"
 #include "platform/image-decoders/ImageDecoder.h"
 #include "platform/image-decoders/ImageFrame.h"
 #include "platform/testing/UnitTestHelpers.h"
@@ skipping 68 matching lines @@
         sourceData[1]->append(source++, 1u);
         // Alternate the buffers to cover the JPEGImageDecoder::onSetData restart code.
         decoder->setData(sourceData[length & 1].get(), length == data->size());
 
         EXPECT_LE(frameCount, decoder->frameCount());
         frameCount = decoder->frameCount();
 
         if (!decoder->isSizeAvailable())
             continue;
 
+        bool frameIsFullyReceived = decoder->frameIsFullyReceivedAtIndex(frameCount - 1);
         ImageFrame* frame = decoder->frameBufferAtIndex(frameCount - 1);
+        if (decoder->filenameExtension() != "webp" || frameIsFullyReceived)

[aleksandar.stojiljkovic, 2016/05/22 15:41:53]

The check is conservative - when frameIsFullyReceivedAtIndex returns true, there
is enough data to get the frame completely decoded.

WebP decoder could rarely return false for frameIsCompleteAtIndex although there
is enough data to get the frame fully decoded.
This happens only for single frame WebP images - frame gets completely decoded 2
bytes before the end of file and WebP demux reports WebPIterator::complete true
2 bytes later or after frame decoding is completed.
Multiframe WebPs used in tests don't expose that type of "byte padding" issue. 

[scroggo_chromium, 2016/05/23 16:40:42]

I'm still not convinced that that is the case. See my other comments about this.
Should we fix that?
But it sounds like that issue might be present in other WebPs?

[aleksandar.stojiljkovic, 2016/05/24 11:08:24]

Looks like the fix would go to libwebp. I'll check with authors.
Anyway, it should not affect this patch as it is not regression. Once fixed, the
test could be fixed too.

The test pass here for used single and multiframe webps. When true, "fully
received" consistent with produced complete frame in decoding. 
I could try with other webp files.
Let me check other files and analyze code deeper to see what is the size of this
padding.

[scroggo_chromium, 2016/05/24 13:55:14]

Please add a comment explaining why you need to special case WebP.

[aleksandar.stojiljkovic, 2016/05/24 19:24:34]

Done.

+            EXPECT_EQ(frameIsFullyReceived, decoder->frameIsCompleteAtIndex(frameCount - 1) || decoder->failed());
         if (frame && frame->getStatus() == ImageFrame::FrameComplete && framesDecoded < frameCount)
             ++framesDecoded;
     }
 
     EXPECT_FALSE(decoder->failed());
     EXPECT_EQ(expectedFrameCount, decoder->frameCount());
     EXPECT_EQ(expectedFrameCount, framesDecoded);
     EXPECT_EQ(expectedRepetitionCount, decoder->repetitionCount());
 
     ASSERT_EQ(expectedFrameCount, baselineHashes.size());
@@ skipping 32 matching lines @@
     // data in a segment, its pointer would no longer be valid.
     segmentedData->data();
 
     ImageFrame* frame = decoder->frameBufferAtIndex(0);
     ASSERT_FALSE(decoder->failed());
     EXPECT_EQ(frame->getStatus(), ImageFrame::FrameComplete);
     EXPECT_EQ(hashBitmap(frame->bitmap()), hash);
 }
 
 } // namespace blink