Closed Bug 17126 Opened 25 years ago Closed 22 years ago

Animated GIFs set by mouseovers only animate first time


(Core :: Graphics: ImageLib, defect, P1)






(Reporter: Coen, Assigned: pavlov)




(Keywords: regression, Whiteboard: [imglib])


(5 files)

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)
Assignee: chofmann → pnunn
Component: other → ImageLib
pnunn for investigation? cc warren.
also cc hyatt.
QA Contact: leger → elig
QA Assigning to self (as should have been done when assigned to pnunn.)
Closed: 25 years ago
Resolution: --- → INVALID
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., if you have evidence to the contrary on a current build, please
read the bug writing guidelines at
guidelines.html, and re-open this bug with your comments, following the format of
the bug writing guidelines.

Resolution: INVALID → ---
sorry guys, didn't upload the images, now they're online too...

	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. ;)
OS: Windows 98 → All
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).
Target Milestone: M13
what's the status on this one? What was the import of your
last comment?
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.
Summary: animated GIF in menu → animated GIFs set by mouseovers do not animate
[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.
Closed: 25 years ago25 years ago
Resolution: --- → WORKSFORME
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
Verifying as WORKSFORME using today's builds on RH Linux 6.0/GNOME, Mac OS 8.6
and NT 4.0 SP5.
OS: All → Windows 98
Summary: animated GIFs set by mouseovers do not animate → *animated* GIFs set by mouseovers do not *animate* (although they do change)
Resolution: WORKSFORME → ---
Using Mozilla 2000011408, Win98, with an "RM 15 inch Multiscan Audio (69kHz
1569ME) on RAGE PRO TURBO AGP 2X (English)", when going to
...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.
Target Milestone: M13 → M16
moving out to m16. Need more time to
duplicate error condition.
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.
Closed: 25 years ago25 years ago
Resolution: --- → WORKSFORME
Using todays Mozilla, when going to
...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.

Resolution: WORKSFORME → ---
Summary: *animated* GIFs set by mouseovers do not *animate* (although they do change) → Animated GIFs set by mouseovers only animate first time
Attached image image1
Attached image image2
Attached image image 3
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,, and

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.

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.

Closed: 25 years ago25 years ago
Resolution: --- → INVALID
Resolution: INVALID → ---
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.

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 Milestone: M16 → M20
*** Bug 41939 has been marked as a duplicate of this bug. ***
From bug 41939,

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
   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


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 

* 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

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).

Target Milestone: M20 → Future
Blocks: 61480
QA Contact: elig → tpreston
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=''>61640</a> and the 
comment by about url resolution. 
the preloaded animated gif shown by window.document.images[picname].src
doesn't appear at 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.
Assignee: pnunn → pavlov
Mozilla interprets the testcase
( 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
*** 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 (
Whiteboard: [imglib]
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
Assignee: pavlov → saari
Target Milestone: Future → ---
I have found this behaviour on a site that I have inherited , 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 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.

I have added a link that allows you to view the tail of apache log on the page

We're probably just going through a code path that doesn't call StartAnimation
on the container. Should be easy, 0.9.2
Target Milestone: --- → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
*** 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
just move over a rectangle ...
adding keywords
OS: Windows 98 → All
*** Bug 21423 has been marked as a duplicate of this bug. ***
*** Bug 86572 has been marked as a duplicate of this bug. ***
Blocks: 66966
See the additional test case
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! ;-)
Hardware: PC → All
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.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
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.
Priority: P3 → P1
would be another example.
Adding "regression keyword since this worked fine in 0.9.1
Keywords: regression
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Still buggin' around. Please take a look at the preloaded buttons on the left 
side on the following example site:

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 [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
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 104166
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Blocks: 119597
similar to another bug I just gave Pav, hopefully he'll have time to look at it...
Assignee: saari → pavlov
Target Milestone: mozilla0.9.8 → ---
Target Milestone: --- → Future
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...

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
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.


Mozilla 0.9.9+
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.9+) Gecko/20020420
Keywords: mozilla1.0.1
*** 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),
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.

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)
<script language="JavaScript">
function UpdateGraphics() {
	window.document.images.progress.src = "timer_05s.gif";
<body bgcolor="#FFFFFF">
<img src="timer_05s.gif" name="progress" width="104" height="12">
minusing for 1.0.1 given the future status of this bug.
Depends on: 152756
isn't this fixed?
using latest trunk build and checking the 
mouseover and the animated gifs are working fine.
Yes, 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"
name="button_test" src="img/button_test.gif" width="130" height="30" border="0"

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,

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 - 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!
Keywords: mozilla1.2
Fixed 2002101010 Win2k

Tested URLs:
Closed: 25 years ago22 years ago
Resolution: --- → FIXED
Not fixed!
WinXP, Mozilla 1.2.1

After page loads, it seems to be OK, but... :
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.
You need to log in before you can comment on or make changes to this bug.