Check for contiguous buffer state.

When we are reading large image data (i.e.: people using webp to stream
video instead of the native webm format; I'm looking at you, Giphy!)
we can run into the situation where the available data is not in a
contiguous buffer, and we need to either buffer additional data or
re-buffer from the start. If we don't do this, we can run into issues
because of buffer over-reading (causing corrupted data if allocated or
more likely crashes if not allocated).
Re-buffering is expensive, but this should be rare and limited to
dealing with unintended use for animated image formats.

This resolves #940.

2 files changed, 11 insertions, 0 deletions

diff --git a/image/SourceBuffer.h b/image/SourceBuffer.h
index 64727e65e2..6f2c74d33b 100644
--- a/image/SourceBuffer.h
+++ b/image/SourceBuffer.h
@@ -174,6 +174,13 @@ public:
     return mState == READY ? mData.mIterating.mNextReadLength : 0;
   }
 
+  /// If we're ready to read, returns whether or not everything available thus
+  /// far has been in the same contiguous buffer.
+  bool IsContiguous() const {
+    MOZ_ASSERT(mState == READY, "Calling IsContiguous() in the wrong state");
+    return mState == READY ? mData.mIterating.mChunk == 0 : false;
+  }
+  
   /// @return a count of the chunks we've advanced through.
   uint32_t ChunkCount() const { return mChunkCount; }
 
diff --git a/image/decoders/nsWebPDecoder.cpp b/image/decoders/nsWebPDecoder.cpp
index 4f3cc8b2ad..3181e3a3ad 100644
--- a/image/decoders/nsWebPDecoder.cpp
+++ b/image/decoders/nsWebPDecoder.cpp
@@ -144,6 +144,10 @@ nsWebPDecoder::UpdateBuffer(SourceBufferIterator& aIterator,
 
   switch (aState) {
     case SourceBufferIterator::READY:
+      if(!aIterator.IsContiguous()) {
+        //We need to buffer. This should be rare, but expensive.
+        break;
+      }
       if (!mData) {
         // For as long as we hold onto an iterator, we know the data pointers
         // to the chunks cannot change underneath us, so save the pointer to