User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/113.0

Steps to reproduce:

Open the attached GIF file in Mozilla Firefox 113.0.2 (64-bit).

Actual results:

GIF is animated and then it stops (does not loop, is not repeated).

Expected results:

GIF animation loop should have been repeated endlessly.

(The same GIF is looping in Internet Explorer 11 and also in ungoogled-chromium 109.0.5414.120-1.1.)

GIFAnimator on Mac won't open this GIF, claims the file is corrupted.

GraphicConverter will open it, and confirms that the loop flag is set on it. Playback within GraphicConverter does loop continuously.

It does loop continuously in Safari on Mac OS Ventura.

Since GIFAnimator thinks it's corrupted, there probably is actually something wrong with the GIF, but Chromium (which is the back end for all the other browsers mentioned) is lenient enough to ignore the problem.

Doing a File > Save As... in GraphicConverter and saving it with Image I/O format results in the same file size, and a GIF that does animate in Firefox.

I don't know enough about the internals of GIF or have sufficient tools to compare what's actually different between the two, but I'll upload the fixed file here for someone else to compare.

Regression wndow:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4495e1f795c2&tochange=259d1556c221

Suspect:
379147b5215f4abe1968e3549973fd83bfdf8bae Gabor Krizsanits — Bug 678465 - 'document-element-inserted' doesn't fire on ImageDocument; r=sicking

Three steps to reproduce the original GIF:

1. Unpack the directory frames100x100 from the attached file frames.7z

2. Download https://gif.ski/gifski-1.10.0.zip and unpack the executable file win\gifski.exe

3. Run the following command on Windows:

gifski --extra --fps 24 --quality 49 --lossy-quality 48 --motion-quality 49 --output result.gif frames100x100*.png

On my machine it yields an exact copy of the original GIF.

If someone untimately finds out what exactly is wrong with the GIF, consider reporting the technical details to https://github.com/ImageOptim/gifski/issues

Oops, Bugzilla supports Markdown now, and thus a backslash is “eaten” before an asterisk.

Here's the correct command for the third step:

gifski --extra --fps 24 --quality 49 --lossy-quality 48 --motion-quality 49 --output result.gif frames100x100\*.png

The original GIF does seem to have an oddity: Frame 20 (bytes 13400 - 13432) only outputs 2 pixels for a 36 pixel image, one of which is transparent. The LZW data block returns 7 codes: RESET, 1, 0, RESET, RESET, RESET, ENDOFIMAGE.

Extracting that frame as a stand-alone GIF, the software I have at hand does a variety of different things:

• Firefox and GIMP complain it's corrupt and won't open it.
• Chromium and Shotwell pretend the 'missing' pixels are transparent.
• GWenView adds an second visible pixel at the trucation point, and then the rest is transparent.
• Krita renders one pixel, but in the wrong location.

If Frame 20's blocks are removed, the GIF loops as expected in Firefox and GIMP can load the file.

Trying to move to a more proper component.

Thanks for the diagnosis and debugging everyone!

(In reply to Alice0775 White from comment #3)

Regression wndow:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4495e1f795c2&tochange=259d1556c221

Suspect:
379147b5215f4abe1968e3549973fd83bfdf8bae Gabor Krizsanits — Bug 678465 - 'document-element-inserted' doesn't fire on ImageDocument; r=sicking

In this range I think probably bug 573583 enable decode-on-draw.

I used all of the provided steps/files here to report the issue to gifski https://github.com/ImageOptim/gifski/issues/301

Thanks for everyone who contributed.

This is similar to this code in image/Decoder.cpp

https://searchfox.org/mozilla-central/rev/ae292ebba6074601b33fa983dd4e01ce6a1ec4ac/image/Decoder.cpp#257

We won't display the frames after the bad frame, but that seems reasonable, and an improvement from current. If we get more reports of this we can look into just skipping the bad frame instead of truncating before the bad frame.

(In reply to Sergey Sokoloff from comment #4)

2. Download https://gif.ski/gifski-1.10.0.zip and unpack the executable file win\gifski.exe

At https://github.com/ImageOptim/gifski/issues/301 it is reported that 1.11 works for them, so perhaps try updating and see if the problem persists for you?

I cannot run gifski 1.11 on my i7-3770 (unlike the previous versions of gifski, it is built to require AVX2).

However, having updated to 1.10.3 instead of it, I see that the problem is gone.

That is a good reason to presume that the problem is fixed by the author (between v1.10.0 and v1.10.3, and thus between the 22th of January and the 16th of March) and that the fix resides somewhere in that dozen of commits.

The scope of this issue is therefore limited to the behaviour of such animated GIF files generated by the older versions of gifski (and not by the future ones) when they're viewed in Firefox.

The severity field is not set for this bug.
:aosmond, could you have a look please?

For more information, please visit BugBot documentation.

Thanks for checking!

There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:tnikkel, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Frustrating bugbot is frustrating.