Do not set m_decodeFailed in ImageFrameGenerator::decodeToYUV

third_party/WebKit/Source/platform/graphics/ImageFrameGenerator.cpp

Index: third_party/WebKit/Source/platform/graphics/ImageFrameGenerator.cpp
diff --git a/third_party/WebKit/Source/platform/graphics/ImageFrameGenerator.cpp b/third_party/WebKit/Source/platform/graphics/ImageFrameGenerator.cpp
index 4800a3141ac19725d605923cccbbcb94373fba80..bd5305211fee3be1c8b5f0b08a8eef75fff9dd0f 100644
--- a/third_party/WebKit/Source/platform/graphics/ImageFrameGenerator.cpp
+++ b/third_party/WebKit/Source/platform/graphics/ImageFrameGenerator.cpp
@@ -248,7 +248,6 @@ bool ImageFrameGenerator::decodeToYUV(size_t index, const SkISize componentSizes
     }
 
     ASSERT(decoder->failed());

[Justin Novosad, 2016/03/24 14:13:57]

Does this assert fire when you try to repro the bug with assertions enabled
(debug build)?

[xidachen, 2016/03/24 14:40:24]

The example loads and calls drawImage() on 25 images, debugging shows that 15 of
them hit this assert which means decoding failed. But 10 of them go into the
above if() block which returns true.

-    m_decodeFailed = true;
     return false;

[Justin Novosad, 2016/03/24 14:13:57]

Can you explain why the decode flow reaches this point if the decode did not
actually fail?  Is there something special about the way the jpegs are encoded?

[Noel Gordon, 2016/03/25 08:16:46]

Concur with these questions.

https://codereview.chromium.org/1719533002 was a the most recent change that
touched the body of the YUV decoding path in the JPEGImageDecoder.  Possible
regression (not sure), bugs is marked NeedsBisect so we can wait for that

But meanwhile, you could try reverting the changes to JPEGImageDecoder routine

  static bool outputRawData(JPEGImageReader* reader, ImagePlanes* imagePlanes)

that got added on https://codereview.chromium.org/1719533002 to see if that
helps?

 }