HTML 5 Application Cache Oddities

I typically use Chrome and because I’m working on a single-page app that leverages the application cache HTML 5 feature I frequently jump into chrome://appcache-internals/ to clear stuff out for testing. I note that very few websites that I visit actually leverage this new feature at this point.

Turns out it’s somewhat pathological to get app cache working correctly across all the popular browsers. All have annoying issues that require special code to work-around.

Chrome and Safari are by far the best behaved in my experience. Registered event listeners are dispatched and everything is almost dead simple. Almost, because if you’re loading an update from a local server (i.e. http://localhost/whatever) the entire cache refresh may occur before your script has registered event handlers. When this happens you get no callbacks. Or maybe you’re on a really slow connection and they just haven’t happened yet. Yuck…

In simple applications, this perhaps isn’t an issue: simply read the actual status and proceed if it’s reasonable, if not register event handlers. However, I want custom UI that’s driven by the download progress event stream and fancy error handling etc. So it’s a pain in the #*&^ to have to special case. What I would like is to be able to register my event handlers and get callbacks.

Firefox is a mess when it comes to app cache: you can never really tell what you’re going to get for event callbacks from FF. They might skip a couple steps, jump straight from a progress event to UPDATEREADY state and not dispatch the associated callback… Or my favorite, silently finish taking an update and sit in DOWNLOADING state indefinitely not signaling completion. Firefox has some serious usability problems despite the fact that the MDN docs are excellent. (I’ll file bugs once I’m actually confident I understand how to work around all the weird cases).

In terms of raw speed to cache, Firefox is by far the fastest in my experience. But it’s still the hardest to get working correctly for the reasons above.

IE 10 (the only version of IE that supports application cache) is actually pretty good with respect to dispatching events to the registered handlers. But there is one major quirk: if version 1 is cached, you update the app cache manifest, and reload they’ll take the update, my logic swaps in the new cache and refreshed the page and IE 10 does the entire dance over again. For what reason I have no idea. Re-iterating, IE 10 (on Win7 anyway) downloads all the files declared in the app cache manifest twice.

Empirically, IE 10 is really very slow to cache. It’s many order of magnitude slower than Chrome/Safari when downloading a cache refresh. This combined with the odd double load behavior results in IE 10 taking significantly longer to cache than any of the other popular browsers. Luckily this happens only once/udpate so it’s not really that big a deal. Unless you’re on a slow connection. And then it’s pretty painful actually.

I’m not 100% confident that I’ve caught all the corner cases yet. Altogether my best so far is a complete hacktrocity:

About Chris Russell
This entry was posted in Compute, Internet, Software and tagged , , . Bookmark the permalink.

Comment on this article

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s