jQuery Cycle - squishing images?

The issue discussed in this question happened to me with a production site, but in addition to Firefox, we saw it in IE.

This is how it should look, with all three fading to different pictures intermittently:

We got these scree开发者_如何学Gonshots from clients:

Abmormally small images:

Weird sized images:

We were able to reproduce it reliably with Firefox with a hard refresh (ctrl-f5), but the only one in our office that could reproduce it in IE was running IE8 on Windows 7, and then not reliably. The client was using IE7, I believe on XP.

I fixed it by setting up the slideshow in $(window).load() instead of $(document).ready(), but I never figured out why it was so hard to reproduce in IE. Management is unsettled by the fact that we could not reliably reproduce it in IE or explain why it happened, and I've been asked to investigate.

Does anyone have an idea? Does the same issue discussed in the linked question apply to IE in certain circumstances? All I can say at this point is "we can't always pin down things like this."

UPDATE: I was able to make it happen reliably in IE by not setting the src attributes in the slideshows until after I set up the slideshow in Javascript. I think this proves it was indeed the same timing issue, just happening more rarely because IE is a different rendering engine. Management is still curious what other circumstances intervened, but I'm confident now that it was indeed a timing issue in all browsers, and our production site is safe from further issues.

Also, I asked the same question on jQuery forums here and was told to explicitly set image sizes in the img elements. This also fixed the issue.

It's explained in the link you posted. It's a timing issue. Sometime the cycle starts early, sometimes not. And 'sometimes' may just be 'almost never' in some browsers.

Starting the cycle in document.ready ensures that all images have been loaded before the cycle starts so the dimensions are properly detected.

It can very well depend on CPU speed, network latency, browser, OS and whatnot.

The reason it's so hard to reproduce consistently is because the environment is very complex, and the results depend on things you don't see right away.

I know this is late in the game, but I, too very recently experienced this problem. It drove me nuts. The solution is, in fact to use the $(window).load event method to start the cycle plugin--it guarantees that all associated page-load activity (including any downloads associated with ANY child elements) is complete before it fires. It works in all of the 'big five' browsers.

In my case, I am displaying images of different sizes and aspect ratios, and populating the image list automatically by using a server-side script to populate a variable containing dynamically created tags for all the image types in a designated directory that I tell it to include. Consequently, I can't include the image width and height in the tags, because I don't know what they are. In order to get around this, at the client side I use cycle's onbefore: to fire a script that dynamically looks at the image being processed and then sets the slideshow container to a width and height matching the photo's native width and height. I display a "Loading xx photos..." message with an animated GIF loader graphic so that the user knows something is going on while the images are downloaded.

The slideshow(s) in question reside in an area on the hangmanhills.org website that is restricted to Hangman Hills Residents' Association members only, so I can't show you the end product.