1835509 - this GIF animation stops and does not loop (is not repeated) in Firefox despite being cyclic in other browsers

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Sergey Sokoloff]

Attachment: Konosuba - grim Kazuma [gifski 100×100 q49 fq48 mq49].gif

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.)

Comment 1

[Dave Miller [:justdave]]

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.

Comment 2

[Dave Miller [:justdave]]

Attachment: Konosuba - grim Kazuma [gifski 100×100 q49 fq48 mq49] GC.gif

Comment 3

[Alice0775 White]

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

Comment 4

[Sergey Sokoloff]

Attachment: frames.7z

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

Comment 5

[Sergey Sokoloff]

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

Comment 6

[M8R-p7]

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.

Comment 7

[M8R-p7]

Attachment: Frame20.gif - Frame 20 of the original GIF animation, presented as a standalone GIF image.

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Trying to move to a more proper component.

Comment 9

[Timothy Nikkel (:tnikkel)]

Thanks for the diagnosis and debugging everyone!

Comment 10

[Timothy Nikkel (:tnikkel)]

(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.

Comment 11

[Timothy Nikkel (:tnikkel)]

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.

Comment 12

[Timothy Nikkel (:tnikkel)]

Attachment: Bug 1835509. If we encounter a bad LZW block in a gif frame still report success if we have decoded frames before this successfully. r?aosmond

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.

Comment 13

[Timothy Nikkel (:tnikkel)]

(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?

Comment 14

[Sergey Sokoloff]

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.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit BugBot documentation.

Comment 16

[Timothy Nikkel (:tnikkel)]

Thanks for checking!

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 18

[Timothy Nikkel (:tnikkel)]

Frustrating bugbot is frustrating.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7ebd26a0e71e
If we encounter a bad LZW block in a gif frame still report success if we have decoded frames before this successfully. r=aosmond

Comment 20

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/7ebd26a0e71e

Comment 21

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on a 2024-02-27 Nightly build on macOS 12.
Verified as fixed on Firefox Nightly 126.0a1 and Firefox 125.0b4 on macOS 12, Windows 10, Ubuntu 22.