But SWFObject is missing a feature. It’s not easy enough to test your non-Flash alternative content. You can bump up the required version number to one that doesn’t exist yet, which is a good way to make sure your expressInstall.swf is working. Or you can follow the directions in their FAQ and disable JavaScript or the Flash Player (17. How to disable Flash Player or JavaScript, e.g. to test alternative content?).
Those solutions take a bit more effort than should be required. What if you want to show a client at another location the alternative content? I’d rather send them a link than walk them through disabling/enabling their JavaScript. And what if you want to take it beyond just testing, and give your users in a live environment the option to view the non-Flash content?
Here’s what I do. The SWFObject API includes a useful method to get query string parameters, ingeniously called getQueryParamValue(), which can be used to grab query string information and then pass it into the SWF via the flashvars array. In this example, I use the method to determine whether or not to embed the SWF in the first place.
Your standard SWFObject embed code will look something like this:
<script type="text/javascript">
var flashvars = {};
var params = {};
var attributes = {};
attributes.id = "flashContent";
swfobject.embedSWF("flashContent.swf", "alternativeContent", "100%", "100%", "9.0.28", "expressInstall.swf", flashvars, params, attributes);
</script>
Here’s my version with a simple if statement to determine if the non-Flash content should be shown.
<script type="text/javascript">
var flashvars = {};
var params = {};
var attributes = {};
attributes.id = "flashContent";
if (swfobject.getQueryParamValue("viewAlt") == "true") {
// This lets us test the alternative content. If "viewAlt" is true in the query string, we don't allow SWFObject to replace the alternativeContent div with the Flash content.
}else{
swfobject.embedSWF("flashContent.swf", "alternativeContent", "100%", "100%", "9.0.28", "expressInstall.swf", flashvars, params, attributes);
}
</script>
So all it takes to view and test the alternative content is to throw ?viewAlt=true at the end of your URL. This will stop SWFObject from ever trying to embed your SWF.
Here is an example of this process in action.
And here is the source.
Flash Preloading Errors? Turn Off gzip.
So what gives? Well, the staging environment was serving SWFs with gzip compression and this was messing up the bytesLoaded and bytesTotal properties that my preloader SWF was trying to read from the main SWF. Different browsers reacted differently too. Some saw bytesTotal as 0 (IE), which is what gave me the infinity percentage (dividing bytesLoaded / 0 will give you Infinity), while others reported bytesTotal as the same as bytesLoaded (Firefox). Hard coding a fake bytesTotal was my temporary fix.
To check to see how your server is sending your files, you can use Charles to inspect your web traffic. Here’s the one that was breaking because of gzip compression:
A SWF served with gzip compression will cause preloading errors.
And here’s what it should look like:
A SWF correctly served without gzip compression.
I originally thought the issue was with the SWF being served with the wrong MIME type of “text/plain” but changing that didn’t fix my problems. The moral of the story is to check these server settings before wasting a Saturday (Gasp? Working on a weekend?) trying different versions of a Flash preloader and waiting for staging to build the site after each try.