955884 - Firefox cannot display large animated GIF correctly

Status: RESOLVED DUPLICATE of bug 523950

(Core :: Graphics: ImageLib, defect)

Description

[Codacoder]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131112160018

Steps to reproduce:

Drop a gif file onto firefox
gif is infinite-loop animated, >300MB created with LICEcap.exe


Actual results:

FF24.2esr : takes way too long to display first frame (~20secs)
  a: sometimes crashes https://crash-stats.mozilla.com/report/index/8eea651d-fcda-49dd-a2cc-264492131231
  b: sometimes locks up.
  c: sometimes plays fine and loops at end
  d: using the magnifier to max the gif will lock up browser
  e: maximizing browser will cause lockup

FF25: plays partway then " -cannot be displayed because it contains errors"
FF26 : not tested
FF27: plays partway then " -cannot be displayed because it contains errors" 

FF28: plays for a minute or so then crash
https://crash-stats.mozilla.com/report/index/84380c0d-2cfe-44df-96b0-6d2452131231
https://crash-stats.mozilla.com/report/index/e85b3ee0-e610-4424-8a34-0c0742131231

FF29: Plays almost the entire gif then gets stuck or crashes
Click refresh and get " -cannot be displayed because it contains errors"
Click refresh again and gif plays and gets stuck at end again

================
For comparison purposes:
Current Chrome plays this gif fine.
FF15: plays and gets stuck at end but will refresh and play without complaint.

In summary, I cannot find a firefox version that will play this gif without issue(s).


Expected results:

Gif should load and play without complaint.

Comment 1

[Codacoder]

The gif:

https://drive.google.com/folderview?id=0BynrzxKOpW9UajVqc0lWdFpSU3c&usp=sharing

Comment 2

[Nicholas Nethercote [inactive]]

I tried it in a trunk build of FF29 on my 64-bit Linux machine with 32 GiB. It took about 20 seconds to start, but then played fine, looped successfully at the end, and magnifying/unmagnifying wasn't a problem.

Just after it looped, about:memory said this:

3,118.83 MB (100.0%) -- explicit
├──2,868.76 MB (91.98%) -- images
│  ├──2,868.72 MB (91.98%) -- content
│  │  ├──2,868.72 MB (91.98%) -- used
│  │  │  ├──2,508.80 MB (80.44%) ── uncompressed-heap
│  │  │  ├────359.92 MB (11.54%) ── raw
│  │  │  └──────0.00 MB (00.00%) ── uncompressed-nonheap
...
3,069.25 MB ── heap-allocated
3,083.51 MB ── heap-committed
...
3,164.64 MB ── resident
3,124.25 MB ── resident-unique
4,566.57 MB ── vsize

Lots of image data there, which isn't surprising.

Firefox on Windows is 32-bit so it's almost certainly an OOM (either virtual or physical) that you're seeing. Chrome on Windows is also 32-bit so it must do a better job of discarding decoded frames along the way.

Comment 3

[Timothy Nikkel (:tnikkel)]

Unfortunately we don't discard animated images at all. Yeah, it's not great at all. As long as the image object exists we will keep around all decoded frames, even if its only in a hidden tab.

The code to handle the extra things (like timers) that animated images need to be correctly discarded and redecoded just hasn't been written yet.

Comment 4

[Codacoder]

Nick - since for most people this would be a rare use case, I'm happy for this bug to be marked "let it fester" ;)  Your call.

Aside: I recently discovered that VLC can do screen capture so there's a good chance I can find another way for our users to send caps to us.

Comment 5

[Nicholas Nethercote [inactive]]

> Nick - since for most people this would be a rare use case, I'm happy for
> this bug to be marked "let it fester" ;)  Your call.

I'll leave it open, but yes, I wouldn't expect a lot of action here due to the rarity of the case.

Comment 6

[Nicholas Nethercote [inactive]]

Oh, this is actually a dup.