Summary: If image animation is set to "none" (see bug 17686, "Preference for animated image display (GIF89a, MNG)", the first frame of any animated gif is displayed, but the image is replaced by its alt text (or URL if none) and the page reflows. Reproducible: Always? Steps to Reproduce: -2 If possible, find an older uniprocessor machine with a slow (modem) internet connection to test with. -1. Start Task Manager (on context menu for blank part of Windows taskbar). 0. Edit prefs.js, adding 'user_pref("image.animation_mode", "none");' and (re)start Mozilla. 1. Load the image at the URL link above (a 2-frame gif). 2. Click on the [Reload] button at least once 3. Switch to the Task Manager window, select the "Processes" tab, and click on the "CPU" column head, and observe the first row for a few seconds. 4. In mozilla, click on the [Back] button. 5. In Task Manager, observe the CPU usage again. Actual results: a) Possibly the crash reported in bug 65016, "Crash on loading an animated GIF"; otherwise: b) The first frame of the gif appears c) The image is replaced by its URL d) (b) and (c) repeat for each press of the reload button e) Mozilla uses as much CPU as is available until another URL is loaded. Expected Results: a) The first frame of the gif is displayed and continues to be displayed until the user navigates away from the URL; nothing else. Tested with: build 2001-01-11-04-talkback on WinNT 4.0 Additional information: The steps to reproduce use a gif for predictability, but the same happens to any number of animated gifs on a webpage -- try http://www.cnn.com/

Occasionally, the first frame actually stays in place; but most of the time, I see what Sean reports. It would be great if the first frame (or at least as much of it as we managed to load) would stay visible, and the width and height tags remain set instead of resetting to zero as they seem to do.

All pnunn bugs reassigned to Pav, who is taking over the imglib.

Sean, can you re-check this on a current build please. I am not seeing the problem but may not be following your steps correctly. Or it might have been fixed in the new imagelib. thx

Right now this will be w.f.m., because with the new imglib, we have Bug 74169, "user pref "image.animation_mode" ignored". In other words, this bug is currently untestable. There's a fix in hand for that bug, waiting for r= and sr=, so making this bug depend on it; will retest this bug once that fix gets included in the nightlies. Sorry I forgot to mention that here earlier!

akkana checked in the patches.. is this still a problem?

Resolving this bug, fixed NT build 2001041704 Fixed in Mac build 2001041704 Fixed in linux build 2001041708

Also working properly with 2001-04-18-04 on WinNT; VERIFYing.