an animated GIF in a menu with preloading of the images does not work, it only displays the last frame onmouseover/out, works fine with MSIE5... (see URL: the white GIF with "basketball" is an animated GIF)

pnunn for investigation? cc warren.

also cc hyatt.

QA Assigning to self (as should have been done when assigned to pnunn.)

I'm resolving this bug as invalid; on IE 5, the page simply displays a column of broken GIF images, which is equivalent to our behavior on Apprunner. Coen@ddsw.nl, if you have evidence to the contrary on a current build, please read the bug writing guidelines at http://www.mozilla.org/quality/bug-writing- guidelines.html, and re-open this bug with your comments, following the format of the bug writing guidelines. Thanks!

sorry guys, didn't upload the images, now they're online too...

Pam, This is most likely not an ImageLib problem, but you probably know who it goes to; if it's not immediately obvious what the bug reporter meant, drop by my cube, and I'll show ya.

Just because IE is also broken here doesn't mean we should be too.

Err...IE wasn't broken; the _page_ was broken. ;)

Hey, Pam --- There's a delay of .1 seconds between frame specified in the control blocks. (As noted while you were here, the behavior on the current build was identical to that of Comm 4.7).

eli: what's the status on this one? What was the import of your last comment? -p

It looks the same on 4.7 and viewer to me. (12-02-99 pc build) except for the background....Which is not this bug. I will file another bug on the bkgrnd problem. Its a file name resolution problem. -pn

[changing summary to more accurately reflect the bug]

I see the image change when I mouse over the image. It works for me. If it doesn't work for someone else, let me know what you see.

This works for me. If you see the bug again and want to reopen it, please add more info on your pc, ie, os version, video display, etc. And what version of of mozilla (by day) are you running. -thanks, p.

Verifying as WORKSFORME using today's builds on RH Linux 6.0/GNOME, Mac OS 8.6 and NT 4.0 SP5.

Using Mozilla 2000011408, Win98, with an "RM 15 inch Multiscan Audio (69kHz 1569ME) on RAGE PRO TURBO AGP 2X (English)", when going to http://www.oli.tudelft.nl/Punch/temp/menu.html ...the "basketball" GIF at the top of the menu does not ANIMATE when doing the mouseover. In Internet Explorer, doing a mouseover on the "basketball" title causes the text to actually *animate* (as well as doing a normal mouseover effect). That is to say, it actually fades in and out, rather than just change colour like the other GIFs on that page. Reopening. If this is not enough info to reproduce, please ask and I will investigate some more.

moving out to m16. Need more time to duplicate error condition. -p

I am seeing the same behaviour in mozilla and in Internet Explorer, i.e. doing a mouseover on the "basketball" title causes the text to actually animate. Eli, could you confirm this?

Marking it worksforme.

Using todays Mozilla, when going to http://www.oli.tudelft.nl/Punch/temp/menu.html ...the "basketball" GIF at the top of the menu only animates ONCE when doing the mouseover. In Internet Explorer, doing a mouseover on the "basketball" title causes the text to animate each time the graphic is moused over. Reopening.

I've attached a simplified version of the page with 3 animated images that are very identifiably different. Though I couldn't _see_ the problem I looked into the possibility that the js mouseover was causing the gif animations to stop. The attached test file shows that mouseovers do not stop the animations. I honestly can not see the gifs on the bug page animate. I have downloaded http://www.oli.tudelft.nl/Punch/temp/images/menu/bball_a.gif, http://www.oli.tudelft.nl/Punch/temp/images/menu/bball_b.gif, and http://www.oli.tudelft.nl/Punch/temp/images/menu/bball.gif. I can verify, using a gif utility, that bball_a.gif and bball_b.gif each have 5 frames and that bball.gif is a single frame image. But when viewing the animations, I can't see much happening. I have tried using several different applications. For the record, I am using a true color display. Please send me a simple test case that shows the problem, or I will have to close this as a WONTFIX. I can't fix what I can't see. -P

the last one is not an animation, the first two are. in the javascript an onmouseover or onmouseout call the first two, which results in MSIE in animation, infinitely. Same in Mozilla couses them to animate just once... (the first time)

Tthe mystery is solved. The animated gifs, bball_a.gif and bball_b.gif don't have headers that specify looping. Most shareware gif animation utilities provide a way to specify parameters for looping. GIFConstructionSet is a popular one. You might want to consider it. -P

Tthe mystery is solved. The animated gifs, bball_a.gif and bball_b.gif don't have headers that specify looping. Most shareware gif animation utilities provide a way to specify parameters for looping. GIFConstructionSet is a popular one. You might want to consider it. -P

they are not in a loop, you are missing the point. They animate once, and they should animate once every onmouseover and onmouseout, but in Mozilla, they only do the first time, in MSIE every time

I can't see this on my machine(s). I can, however, see it on eli's mac. I'll reopen this, but have to give it a later target.

*** Bug 41939 has been marked as a duplicate of this bug. ***

From bug 41939, http://www.dessertsdivine.com/mozilla/testcase.html Notice the difference between IE 5.01 and Mozilla

*** Bug 41939 has been marked as a duplicate of this bug. ***

The same bug in different guise? 1. Open http://members.netscapeonline.co.uk/valeriegsharp/anim1-test/ in Mozilla (I'm using M16). Observe that the animated 'cloud' GIF runs only once, although it is allocated to different objects at different Timer Intervals. (Compare with MSIE 5). This looks like another form of the same bug. 2. Notice that the animation will run again on Reload. 3. However, open a new browser window, and Open Web Location to the same web page - so you now have two browser windows showing the same page. 4. Notice that the animation will not run at all on Reload in either window. 5. Close one of the Browser windows. 6. Now the animation will rerun on Reload as before. This may be another consequence of the same bug, but if not then I will raise another bug report.

One of the websites my company developed is a victim of this bug, so I've spent a while looking into it. I made a web page with what I found at <http://www.geocities.com/jasperjjjjjj/index.html> Basically, Mozilla is consistent with NN 4.x, but both behave incorrectly. IE 5 (on Windows) behaves correctly. I can't check other browsers/platforms right now. * Scenario: "before.gif" = normal gif (no animation) "after.gif" = animated gif (no looping) OnMouseOver -- "before.gif" is replaced with "after.gif" * Expected behavior: On the first mouse-over, "before.gif" should be replaced by "after.gif" and "after.gif" should animate once and stop. On all subsequent mouse-overs, "after.gif" should animate once and stop. I think this behavior is intuitive, and makes the most sense. * Actual behavior IE 5: works NN 4.x and Mozilla (7/6/00 widows build): If "after.gif" is preloaded with javascript, the first mouse-over replaces "before.gif" with the *last frame* of "after.gif" (it does not animate). Subsequent mouse-overs do nothing. If "after.gif" is NOT preloaded with javascript, the first mouse-over replaces "before.gif" with "after.gif" and the animation runs once (this is the correct behavior). Subsequent mouse-overs, however, do nothing. See the grocities link above to see all of this in action. I hope this helps.

Thank you very much, Jamie!

Wanted to ask if this is the same bug or not. Take a look at http://www.aladdincasino.com/navigation.html On M17, when I move the mouse over one of the items, it is supposed to switch to an animated image. Instead, the images just disappear and don't reappear. If this isn't the same problem then I'll go ahead and open a new one (or someone else can, and let me know so I don't).

I can confirm the behavior observed by Erik. The same problem occures with current versions (Moz 0.6, NS6 Netbiz, Beonex 0.6 all on WinNT): Animated rollover images tend to disappear from time to time (not always but often). They are just replaced by their "alt" text. Note: Compare bug <a href='http://bugzilla.mozilla.org/show_bug.cgi?id=61640'>61640</a> and the comment by pnunn@netscape.com about url resolution.

the preloaded animated gif shown by window.document.images[picname].src doesn't appear at http://www.infraroth.de in nav.html it works in almost all browsers but mozilla 0.6 2000122604, ns 6.0, and opera 5.0

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

Mozilla interprets the testcase (http://www.geocities.com/jasperjjjjjj/index.html) differently now but it is still incorrect. The flower image is supposed to bloom once and stop on each mouseover. According to what is written on the page, when this bug was first filed the flowers bloomed once only on the first mouseover but now in build 2001032904 they blooms in a continuous loop. Should this be filed as a new bug? BTW, I got here because I found a similar problem on on another page (http://dpreview.com)

*** Bug 73450 has been marked as a duplicate of this bug. ***

pav, not sure that this should continue in this bug in that the behavior has changed, I do see the continuous looping in win 2001040204, in linux build 2001040208 the flowers do not bloom, the animation is messed up and shows black animation (like lightening) and in mac build 2001040208 the flowers continuously loop (http://www.geocities.com/jasperjjjjjj/index.html)

Is bug #21423 a dup of this?

The new problem with animated gifs that should stop after one run-through looping is reported as bug 75828, "Mozilla repeating animation of images when it shouldn't", which has a patch already. Close this now rather than morphing it into a DUP?

over to saari

I have found this behaviour on a site that I have inherited http://www.largesalad.co.uk/TTG/readings.htm , using build 2001051608 on Linux RH7.0/2.2.16-22. Can't try it on any other OS ATM. Using the above mentioned build, the animation only runs the first time the image.src value is changed by javascript. I have put together a test case from the page with a debug alert in it at http://213.107.42.243/TTG/readings.htm. If you look at it with IE, redirect takes you to a page without the alert(not really needed as it works correctly). When viewed in NS 4.x or IE 4.x/5.x(by a redirect for browser dependant stuff) both on win98, the page works as expected and described on the page. NS 4.x under linux has always been broken for this page, although there are no javascript errors and the expected end result occurs(a new page is shown in its own window). I have <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> in the head(ouch) and the animated gif is not preloaded. Dave

I have added a link that allows you to view the tail of apache log on the page at http://213.107.42.243/TTG/readings.htm. hth

We're probably just going through a code path that doesn't call StartAnimation on the container. Should be easy, 0.9.2

*** Bug 85175 has been marked as a duplicate of this bug. ***

*** Bug 85435 has been marked as a duplicate of this bug. ***

See this also on win2k at http://www.world-direct.com/central just move over a rectangle ...

adding keywords OS->All

*** Bug 21423 has been marked as a duplicate of this bug. ***

*** Bug 86572 has been marked as a duplicate of this bug. ***

See the additional test case http://bugzilla.mozilla.org/showattachment.cgi?attach_id=39088 that I developed for Bug #86572.

I just realized: This bug dates back to 1999. Either my bug 86572 isn't really a duplicate of this, or there's been a regression. Mozilla 0.7 passes my test case.

*** Bug 87282 has been marked as a duplicate of this bug. ***

*** Bug 87282 has been marked as a duplicate of this bug. ***

*** Bug 87282 has been marked as a duplicate of this bug. ***

We need a new keyword: 3xp. This is actually a Nav3.x parity bug! ;-)

mozilla0.9.2->mozilla0.9.3 nsbeta2->nsbeta1

Now that the test case works, the behavior looks the same in Mozilla 0.7, Mozilla 0.9, and Mac IE 5.0 (initially vertical, moves rightward onMouseOver, moves leftward onMouseOut). In Netscape 4.77, onMouseOut seems to reset it and keep moving rightward. Since the test case for my own bug 86572 passes in Mozilla 0.7 and fails in 0.9, I no longer believe it's a dupe of this bug.

This case works now, but looks pathetic (flashing, almost like the cache is missing or decoding a lot, or going to the wire). I want to investigate why.

http://www.payplus.at/footer.asp would be another example. Adding "regression keyword since this worked fine in 0.9.1

->0.9.5

Still buggin' around. Please take a look at the preloaded buttons on the left side on the following example site: http://stardust.adwww.de/ These are _animated_, _transparent background_ GIFs. Bugs in Mozi: No transparence at all, only the first, respectively the last frame are being displayed. Works fine in IE 4.X or higher versions. Not sure, if the problem is really in ImageLib rather than in some caching or buffering modules...

Can you file a separate bug on ImageLib for what you note above about http://stardust.adwww.de/. [And note that ImageLib also includes (most) aspects of managing the request from netwerk/cache and handing off to overall page layout].

*** Bug 97263 has been marked as a duplicate of this bug. ***

-> 0.9.6

similar to another bug I just gave Pav, hopefully he'll have time to look at it...

seems to me that the images here don't animate in moz anymore... build 2002020603 win32

scratch what I said, moz seems to have turned off animation looping for me without my consent.... grr

I just encountered this bug in a page I created... http://www.engin.umd.umich.edu/~npietran top links should fade white -> yellow. Instead they just jump.

Animated Gifs that are set to run once do not run again after refreshing the page. 1. Go to http://www.hhmi.org/coolscience/butterfly/index.html 2. Let the animation run through. 3. Click on refresh or drill ctrl + r Result: Page loads again but the animation doesn't run again. Expected result: Animation runs again as result of refreshing the page. My settings in images are: Let the animation run as many times as it is set to run. Using: Mozilla 0.9.9+ Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.9+) Gecko/20020420

*** Bug 141555 has been marked as a duplicate of this bug. ***

This worksforme in 2002050204, win2K, trunk. Did it magically get fixed by something else?

it does NOT work for me in 1.0-RC2 build 2002051006 (win nt 4.0), see http://habarti.webz.cz/main_hrbitov.html

Strange. This seems to be coming and going. When comment 79 popped into my mailbox I tried a couple of pages and nothing worked. Then I opened this bug and clicked the testcase mentioned in comment 75, and now it suddenly works. I still have the window open in the background, have triple-checked - the mouseovers animate every time. This is 2002051208 trunk, win2K.

Rollovers Work about 99% of the time on the page I posted in comment #75. Mandrake Linux 8.2 Mozilla RC2 (2002051009) If I click through the links and touch the buttons, once in a great while I'll get one that just "jumps" to the last frame.

Here's a simplified sample with only one single animated GIF and a JavaScript timer that reloads the image. The progress bar is restarted every 5 seconds. http://www.selbst-repariert.de/timer.html Works with IE 5.x and Netscape 4.7x (W98, 2k). In Mozilla 1.0rc1 (w98,2k), 1.0rc2 (Suse8.0) it's only animated once. The code used (if the page expires) <html> <head> <script language="JavaScript"> function UpdateGraphics() { window.document.images.progress.src = "timer_05s.gif"; window.setTimeout("UpdateGraphics()",5000); } window.setTimeout("UpdateGraphics()",5000); </script> </head> <body bgcolor="#FFFFFF"> <img src="timer_05s.gif" name="progress" width="104" height="12"> </body> </html>

minusing for 1.0.1 given the future status of this bug.

isn't this fixed? using latest trunk build and checking http://www.central-soelden.com the mouseover and the animated gifs are working fine.

Yes, http://www.central-soelden.com does appear to work, asdoes the testcase in attachment 40602 [details], however, Comment #82 does not work correctly. I suspect that the ones that do work, work because of another bug (can't remember the #) where images are being reloaded from the network everytime src is set. Once the bug is fixed and the memory cache is used again (which is what comment #82 does by setting src to the same value), they probably won't work once again. That's my theory

I can confirm that I have this problem too. I created a simple web page that has this code: <a href="index.html" onMouseOver="javascript:document.button_test.src='img/button_test_anim_up.gif'" onMouseOut="javascript:document.button_test.src='img/button_test_anim_down.gif'"><img name="button_test" src="img/button_test.gif" width="130" height="30" border="0" alt="Test"></a> This line produces a button which consists of a image. When you move the mousecursor over this button the image animates into a new image. When you remove your mousecursor from the button the image animates into the original image. The images that where used: img/button_test.gif (not an animated gif) img/button_test_anim_up.gif (animated gif) img/button_test_anim_down.gif (animated gif) The problem: In Mozilla 1.0 and Mozilla 1.1 the animations only work once. When you move your mousecursor over the button again the animation just jumps into the last frame of the animation. In MSIE 6.0.2600.0000 the animations animates everytime. My problem seems to be the same as that one found in comment #75, http://www.engin.umd.umich.edu/~npietran/. More confusion: Actually while I was writing this bugreport I decided to check with Mozilla 1.1 that the problem occourd again and then it worked (Mozilla presented same behaivor as MSIE 6). When it worked I had have Mozilla active for some time and had opend several pages. But the bug reappeard when I closed down my previous mozilla session and started a new one to open my page =(. So to verify this bug I suggest that you restart your mozilla and load the page. My OS is Windows 2000 SP3.

I have the same problem with 1.0.1 and 1.1 versions of mozilla on Win32 and Linux x86... try http://www.kommunikator.dk - press the "personer" link and move the pointer to images 4 and 8 which are animated... After seeing that they are in fact animated, move the pointer away from the picture then back over it and see how it is no longer animated!

Fixed 2002101010 Win2k Tested URLs: http://www.kommunikator.dk http://www.engin.umd.umich.edu/~npietran/ http://www.selbst-repariert.de/timer.html http://habarti.webz.cz/main_hrbitov.html

Not fixed! http://habarti.webz.cz/main_hrbitov.html WinXP, Mozilla 1.2.1 After page loads, it seems to be OK, but... http://habarti.webz.cz/main_hrbitov.html : 1. Move mouse below image with yellow label "Ota z Bergova", 2. then move mouse into that image, 3. then move mouse into next image on the right: it has yellow label "Jan Marsik..." 4. then move mouse below that image... 5. the animated gif set by on-exit mouseover shows only last frame!! If you only try 1., 2., 4. - it seems to be ok... There are more situations, where this problem is not fixed, generaly: if the same gif is used on the page more times, for first on-enter and on-exit mouse move behave correctly, but second try on-exit mouse move does not play animation.

In Mozilla, all same-src images show the same frame. Initially, all the coffins are rms.gif. On first mouseout, one of the coffins turns to rmn.gif, and animates. When a mouseout on another coffin, it gets set to rmn.gif too. rmn is already on the page, so reanimation does not occur (if it did, both images would animate, and that'd be bad!)

Should we open a new bug about that then?

If you wish, but check to see if one has been filed already. I suspect someone will just mark the bug as WONTFIX, however (or ignored). I wasn't around when the decision was made to make mutliple images of the same URL use the same object, but I can guess the reasons for doing this was to limit memory consumption. Imagine a 50k image displayed 20 times on a page. In the current system, 50k would be used, which is far better then using 1000k.