Comment 1:

This could be a feature.  Now that I've looked at it in Chrome, I can't unsee that gif.

Labels changed: added priority-later, removed priority-triage.

Owner changed to @nigeltao.

Status changed to Accepted.

Comment 3 by kballard:

For the record, Safari/Preview on Mountain Lion render this GIF correctly now as well.

Comment 4:

Labels changed: added go1.1maybe.

Comment 5:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

Comment 6 by jeff.allen:

I looked into this a bit. I found that when the invalid code is found:
code 639
litwidth 8
width 12
clear 256
eof 257
hi 90
ovf 4096
last 98
Because 639 < 90 (d.hi), it fails. I'll trace through another gif decoder and try to
see what they do when receiving a code like this.

Comment 7 by jeff.allen:

Another GIF that causes Go problems:
https://bug525326.bugzilla.mozilla.org/attachment.cgi?id=409291
Don't know if it is the same problem yet, if not, I'll file a new bug.

Comment 8 by jeff.allen:

I suspect this code in Webkit shows the way to making Go's gif decoder more lenient:
http://trac.webkit.org/browser/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageReader.cpp?rev=131831#L322
More later.

Comment 9 by jeff.allen:

A fix for this would involve making compress/lzw tolerant of incorrectly encoded
streams. This seems like a bad idea in general. So a correct fix would need to add to
the API of compress/lzw a boolean for "tolerate errors?".
An API change to compress/lzw before Go 1.1 is not going to happen, so I think punting
on this is the right call.
The image in comment #7 is something else (issue #5050).

Comment 10 by jeff.allen:

I think closing this as Won't Fix would be a good idea. Thanks.

Comment 11:

Status changed to WorkingAsIntended.