Closed Bug 955884 Opened 6 years ago Closed 6 years ago
Firefox cannot display large animated GIF correctly
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.
Component: Untriaged → ImageLib
Product: Firefox → Core
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.