Closed Bug 1303427 Opened 3 years ago Closed 3 years ago
1x1 truncated GIF are white instead of in color
Reported on reddit: https://www.reddit.com/r/firefox/comments/530vv2/gif_with_1pixel_dont_load_in_firefox_but_works_in/ Testcase: https://jsfiddle.net/x0y9j82c/ (renders in color in Chrome) /u/jotted writes: >It looks like the data is truncated in the broken files. >The broken ones have an LZW Block Size of 1 byte, with a Code Size of 3 bits. >There are three codes though - Clear, the Pixel Data and End of Information - >that's 9 bits, which needs 2 bytes of space. The End of Information code gets >cut off and never arrives. >So (wild guessing) it might previously have taken reading past the end of the >block as an implicit EOI, but now it doesn't. >Not sure why it'd return white though, unless that's some sort of failsafe.
Summary: 1x1 truncated pixel is white instead of green → 1x1 truncated GIF is white instead of green
Summary: 1x1 truncated GIF is white instead of green → 1x1 truncated GIF are white instead of in color
Works against the given link. I created a gtest case using the linked truncated images as well, but I need to craft our own to land (and imagemagick isn't cooperating for 1x1 images).
Assignee: nobody → aosmond
Status: NEW → ASSIGNED
Add custom crafted 1x1 green image and test case.
Comment on attachment 8792497 [details] [diff] [review] Still parse buffered LZW codes even if input stream is empty, v2 Thanks for fixing this.
Attachment #8792497 - Flags: review?(tnikkel) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/590b6787d6ef Continue parsing buffered LZW codes in GIFs even if input stream is complete. r=tn
You need to log in before you can comment on or make changes to this bug.