Meta

Flash Preloading Errors? Turn Off gzip.

While finishing up a project a couple months ago, I ran into a problem trying to preload a SWF. Everything worked fine in my development environment. I was throttling my bandwidth using Charles to test things, and the preloader was working as expected. But when I posted it to staging my Flash preloader was broken. My loading bar was animating backwards and my percentage was coming back as infinity.

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.

I’m glad I could help, Natan. And thanks for being my first commenter.

I used two SWFs in this project because I used SWFAddress for deep linking in Flash. To achieve this, SWFAddress adds a # to the URL which will mess up your preloading if a user goes directly to a deep link. This is discussed in the SWFAddress forum (search for c.swf). Basically, the # forces SWFs in the page to fully load before displaying and adding a intermediary SWF is the fix.

That said, I don’t think the second SWF is necessary. Your main SWF should be able to display its own preloader if it’s set up correctly.

Tabitha

Thank you thank you thank you! I was having this exact problem on a client site and finally stumbled upon your blog. I used the program you mentioned (Charles), and sure enough…gzip compression! As soon as that was turned off, everything worked fine. You have saved me.

Back in the day when they released the FLV file format, I had to configure IIS to serve these new videos with the video/x-flv MIME type. That’s why I used Charles to see what was up. And that showed the wrong MIME type along with the other discrepancy of the gzip in the Response Compression.

It seems like some people turn gzip on for everything thinking it will save bandwidth. But compiled SWF files are already about as compressed as they are going to get (the same goes for some image and video files I think). So you’re just wasting processing power/time to compress these files.

Unfortunately, I’m not an Apache expert. I just asked the client to have their server admins fix it.

Try some searches for mod_deflate and mod_gzip. I think the gist of it is that when you configure one of these compression modules, you can add file types to an exclusion list, or you can specifically tell it what types to include in its compression.

awesome job figuring out this issue, debugging this on a project of mine was a pain. thanks!

Roosevelt

Total n00b here! I have this problem but I am in a hosted enviornment (e.g. i don’t have the ability to turn off gzip). How do I fix this problem. Again total n00b here so if you can be detailed and I’d be forever in your debt!

Found this article just after I solved the problem…
Good that you shared this information. It’s weird how the gzip it’s changes the MIME type.
I did this to my .htaccess
<FilesMatch "(?i)^.*\.(htm|html|shtml|php|txt|xml|js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>

Thanks for sharing Charles. A real find, saved me when I had to update the DNS entries on my Mac (changing the hosts file no longer worked).
Anyways …
I also had issues with a gzipped environment, had to write an additional fall back preloader that had an indeterminate state. Just displays bytes loaded. That way it never fails. You can see it running here in the two states.flash preloader

On this one server I’m working with, hard-coding the total file size doesn’t even make a difference. That temporary fix has always worked for me before.
Here the file thinks it’s completed when the preloader has only loaded to about 1/3.

Do you think it’s possible to make the flash file work fine with gzip?
Why do all the other files on the page (images, js, etc.) still work fine?