Animated GIFs set by mouseovers only animate first time

RESOLVED FIXED in Future

Status

()

Core
ImageLib
P1
normal
RESOLVED FIXED
19 years ago
4 years ago

People

(Reporter: Coen van der Poll, Assigned: Stuart Parmenter)

Tracking

({regression})

Trunk
Future
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [imglib], URL)

Attachments

(5 attachments)

(Reporter)

Description

19 years ago
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)

Updated

19 years ago
Assignee: chofmann → pnunn
Component: other → ImageLib

Comment 1

19 years ago
pnunn for investigation? cc warren.

Comment 2

19 years ago
also cc hyatt.

Updated

19 years ago
QA Contact: leger → elig

Comment 3

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

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID

Comment 4

19 years ago
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!

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Updated

19 years ago
Status: VERIFIED → REOPENED
(Reporter)

Updated

19 years ago
Resolution: INVALID → ---
(Reporter)

Comment 5

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

Comment 6

19 years ago
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.

Comment 7

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

Comment 8

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

Updated

19 years ago
OS: Windows 98 → All

Comment 9

19 years ago
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).

Updated

19 years ago
Target Milestone: M13

Comment 10

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

Comment 11

19 years ago
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
Summary: animated GIF in menu → animated GIFs set by mouseovers do not animate
[changing summary to more accurately reflect the bug]

Comment 13

19 years ago
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.

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → WORKSFORME

Comment 14

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 15

19 years ago
Verifying as WORKSFORME using today's builds on RH Linux 6.0/GNOME, Mac OS 8.6
and NT 4.0 SP5.
Status: VERIFIED → REOPENED
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
   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.

Updated

19 years ago
Target Milestone: M13 → M16

Comment 17

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

Comment 18

18 years ago
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?

Comment 19

18 years ago
Marking it worksforme.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → 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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: *animated* GIFs set by mouseovers do not *animate* (although they do change) → Animated GIFs set by mouseovers only animate first time

Comment 21

18 years ago
Created attachment 6864 [details]
simplified version of js page

Comment 22

18 years ago
Created attachment 6865 [details]
image1

Comment 23

18 years ago
Created attachment 6866 [details]
image2

Comment 24

18 years ago
Created attachment 6868 [details]
image 3

Comment 25

18 years ago
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
(Reporter)

Comment 26

18 years ago
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)

Comment 27

18 years ago
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
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → INVALID

Updated

18 years ago
Resolution: INVALID → ---

Comment 28

18 years ago
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
(Reporter)

Comment 29

18 years ago
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

Comment 30

18 years ago
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.
Status: RESOLVED → REOPENED

Updated

18 years ago
Target Milestone: M16 → M20

Comment 31

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

Comment 32

18 years ago
From bug 41939, 

http://www.dessertsdivine.com/mozilla/testcase.html

Notice the difference between IE 5.01 and Mozilla

Comment 33

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

Comment 34

18 years ago
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.

Comment 35

18 years ago
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.

Comment 36

18 years ago
Thank you very much, Jamie!

Comment 37

18 years ago
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).


Updated

18 years ago
Target Milestone: M20 → Future

Updated

18 years ago
Blocks: 61480

Updated

18 years ago
QA Contact: elig → tpreston

Comment 38

18 years ago
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. 

Comment 39

18 years ago
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

Comment 40

17 years ago
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Status: REOPENED → NEW

Comment 41

17 years ago
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)

Comment 42

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

Comment 43

17 years ago
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)
Whiteboard: [imglib]

Comment 44

17 years ago
Is bug #21423 a dup of this?

Comment 45

17 years ago
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?
(Assignee)

Comment 46

17 years ago
over to saari
Assignee: pavlov → saari
Target Milestone: Future → ---

Comment 47

17 years ago
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

Comment 48

17 years ago
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

Comment 49

17 years ago
We're probably just going through a code path that doesn't call StartAnimation
on the container. Should be easy, 0.9.2
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2

Updated

17 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 50

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

Comment 51

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

Comment 52

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

Comment 53

17 years ago
adding keywords
OS->All
Keywords: correctness, mozilla0.9.2, nsbeta2
OS: Windows 98 → All

Comment 54

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

Comment 55

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

Updated

17 years ago
Blocks: 66966

Comment 56

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

Comment 57

17 years ago
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.

Comment 58

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

Comment 59

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

Comment 60

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

Comment 61

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

Comment 62

17 years ago
mozilla0.9.2->mozilla0.9.3
nsbeta2->nsbeta1
Keywords: mozilla0.9.2, nsbeta2 → mozilla0.9.3, nsbeta1
Hardware: PC → All

Comment 63

17 years ago
Created attachment 40602 [details]
Corrected test case; same as first 03/23/00 attachment but uses the three 03/23/00 images.

Comment 64

17 years ago
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

Comment 65

17 years ago
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

Comment 66

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

Comment 67

17 years ago
->0.9.5

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 68

17 years ago
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...

Comment 69

17 years ago
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].

Comment 70

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

Comment 71

17 years ago
-> 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Updated

17 years ago
Blocks: 104166

Updated

17 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Updated

17 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Updated

17 years ago
Blocks: 119597

Comment 72

17 years ago
similar to another bug I just gave Pav, hopefully he'll have time to look at it...
Assignee: saari → pavlov
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.8 → ---
(Assignee)

Updated

17 years ago
Target Milestone: --- → Future

Comment 73

17 years ago
seems to me that the images here don't animate in moz anymore...

build 2002020603 win32

Comment 74

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

Comment 75

16 years ago
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.

Comment 76

16 years ago
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

Updated

16 years ago
Keywords: mozilla1.0.1

Comment 77

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

Comment 78

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

Comment 79

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

Comment 80

16 years ago
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.

Comment 81

16 years ago
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.

Comment 82

16 years ago
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>

Comment 83

16 years ago
minusing for 1.0.1 given the future status of this bug.
Keywords: mozilla1.0.1 → mozilla1.0.1-

Updated

16 years ago
Depends on: 152756

Comment 84

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

Comment 85

16 years ago
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

Comment 86

16 years ago
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!

Updated

16 years ago
Keywords: mozilla1.2

Comment 88

16 years ago
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
Status: NEW → RESOLVED
Last Resolved: 18 years ago16 years ago
Resolution: --- → FIXED

Comment 89

16 years ago
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.

Comment 90

16 years ago
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!)

Comment 91

16 years ago
Should we open a new bug about that then?

Comment 92

16 years ago
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.