Desktop Firefox, Edge, and Safari loop it.
Desktop Chrome on Mac v54.0.2840.71 loops it.
Desktop Chrome on Win10 v54.0.2840.71 is not looping.

It is odd that I'm seeing differences between Windows and Mac.

I walked through the file a bit more in a hex editor.
The file's structure is:
--Header
----GIF89a
--Logical screen descriptor
----canvas width 1366
----canvas height 768
----global color table flag 1
----color resolution 8bpp
----sort flag 0
----size of color table 111
----background color index 0
----pixel aspect ratio 0
--global color table
----since the color table size was 111, this will have 256 entries, 768 bytes
----it starts at byte offset 13, meaning it ends at byte offset 781
--byte 781, application extension
----loop count 0 (infinite)

This ends at memory offset 0x320

Interestingly, this file does not end with 3B like a gif should.
I'll continue the investigation.

Definitely weird that it behaves differently between Mac and Win. My guess was that it was the same as issue 267883, but that doesn't explain the platform difference.

I completely agree.
I tried opening the file with my personal copy of Photoshop at home and Photoshop said the file had an error in it. I suspect there is a problem with the file.

But like you said, I can't make sense of the platform difference.

I just tried Linux ToT 56.0.2906.0 (Developer Build) (64-bit) and it loops correctly.
However, Linux 53.0.2785.143 (Developer Build) (32-bit) did not loop correctly.


I suspect the platform difference is because something got cherry-picked into the Mac release but didn't make it in time for the Windows release. But I feel better knowing that Linux ToT is working.


I'll try Windows ToT.

My current guess as to the cause was me purging before the current frame is completed.  https://crbug.com/652046 

Windows ToT is working.

Either this has been fixed since M54 or it is based on transient behavior like image cache.

I don't want to close this until I'm certain. I'll do a bisect next.

I just did a bisect between 53.0.2785.143 (I can see this is version is bad -- this is what I'm using as a daily driver right now) and ToT 56.0.2906.0 on linux64. Both worked correctly when bisecting. But I know this version of 53 is bad.

So I believe this is a transient issue. It may be related to memory pressure, perhaps? When bisecting / building I had no memory pressure on the fresh run. And my daily driver has more memory pressure, since it is filled to the brim with tabs. Maybe this has to do with the image cache?

I'm putting this on the back-burner for now.

The issue is not easy to reproduce with a fresh build and only effects malformed gifs. So it will be difficult and isn't a common problem. That gives it a very low priority.

> So I believe this is a transient issue. It may be related to memory pressure,
> perhaps? When bisecting / building I had no memory pressure on the fresh run.
> And my daily driver has more memory pressure, since it is filled to the brim
> with tabs. Maybe this has to do with the image cache?

This could definitely be related to memory pressure - if we're unable to allocate memory for a frame, we call SetFailed. If we've failed, we don't try to loop (see GIFImageDecoder::RepetitionCount()). So we draw the blank frame that wasn't allocated, and then don't try to do anything further.

> The issue is not easy to reproduce with a fresh build and only effects malformed gifs.

If my hunch is correct, this doesn't have anything to do with the fact that the gif is malformed. (And it looks to me like the only problem is that it's missing the trailing 3B.) But the fact that it is very large does make a difference.

> So it will be difficult and isn't a common problem. That gives it a very low priority.

I recommend even lower - WontFix

I completely agree with your analysis. Good thinking.