Hi Byron,

I am trying to use cycleResumeOnHover:true but the animation still starts from the beginning.

<div class="box slideshow last-box fbCycler" data-fb-options="cycleInterval:4.5 altAsCaption:true cycleResumeOnHover:true">
		<img src="gfx/content/slide-mini-1.jpg" alt="This is a longer text" />
		<img data-fb-src="gfx/content/slide-mini-2.jpg" alt="TEST2" />
		<img data-fb-src="gfx/content/slide-mini-3.jpg" alt="TEST3" />
	</div>

What am I doing wrong?

Maybe I just start to understand what that functions actually does.
What happens on my page now is that the cycle goes through all images and then stops. When I then hover the image the cycle starts again.

What I would like to see is that the animation only starts in general, when I hover the first image - so basically a cycle starting on mouseover only.

Looks like a bug. When cycleResumeOnHover is set, the cycler set should be in a paused state when the page loads, and should cycle only when the mouse cursor is hovered over the images. The initial paused state is failing to get applied. I don't know of a workaround other than waiting for the next release when this will be fixed.

Good to know.
So I will proceed with my ideas about the implementation of this feature into a clients website once the functionality is fixed.

The cycler function in general seems to be somewhat buggy in the current FB version.
I have the cycler running on a development site and sometimes when I switch to the tab in Firefox with the slideshow in it there is no image visible for a moment and than suddenly the cycler starts fading images again. It seems that for some reason there is a gap in the cycling and sometimes no image is visible. (FF 19.0 on Windows 7)

When I am just watching the cycler doing its job the gap does not seem to appear. Strange!

Do you have any idea when you will launch the next release?

This is bad behaviour on Firefox's part, not Floatbox's part. The animations, including cycler fades, are done with requestAnimationFrame. When a tab is not active in Firefox, it does not do the requested animations, but instead saves them in a queue. When the tab becomes active, it executes the stream of animations from the queue, catching the page up to what we requested it to be. You're seeing a flurry of opacity changes that were requested in an orderly fashion while the tab was inactive. The Firefox crew chose to do things this way to minimize cpu usage, with the sacrifice of a clean rendering when a page comes out of an idle state.

How much does this matter? I mean, will real site visitors be loading the site in an inactive tab? Will they be bothered by the little flurry of catch-up animations if they do? Are we looking at something that a site tester can force but that really won't be happening for 'normal' people using the site?

Hi Byron,

thanks for taking your time on this.

I actually think for real visitors it does not matter so much.
Of course it might happen that somebody has a few tabs open, comes back to the page and sees an empty space where the slideshow is supposed to happen.
I can life with that but of course it would be nice of there is a solution for it.