Closed Bug 955884 Opened 6 years ago Closed 6 years ago

Firefox cannot display large animated GIF correctly

Categories

(Core :: ImageLib, defect)

25 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 523950

People

(Reporter: codacodercodacoder, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [MemShrink])

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.
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.
Blocks: image-suck
Component: Untriaged → ImageLib
Product: Firefox → Core
Whiteboard: [MemShrink]
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.
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.
> 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.
Oh, this is actually a dup.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 523950
You need to log in before you can comment on or make changes to this bug.