The Joy of Flex

As everyone in the universe already knows, last week Adobe released a new beta version of Player 9 code named “Moviestar” that supports additional video codecs. Once we started using the new player ourselves, we discovered that it also contains a change to the way that the XML class handles encoding of XML character entities. We store Buzzword documents as XML on the server, and we use the XML class extensively on the client. So in order to avoid the possibility that users running Moviestar would create incorrectly formed documents, we had to update our client to be aware of the new player behavior.

Here are some details about the change to XML processing in Moviestar, provided in the hopes that, if the change also affects your code, you’ll be able to react quickly too. I’m not promising that this information is absolutely correct and complete; it’s just my best understanding, and you should use it only as a starting point to aid your own testing.

In publicly available versions of the Flash Player previous to 9.0.60.184, when you added a text node to an object of type XML, the built-in character entity characters &, \, ‘, “, <, and > were not encoded as XML character entities, but simply inserted into the XML unencoded. Because of this behavior, long ago we had written wrote preprocessing code to do the character encoding ourselves. However, in 9.0.60.184 (“Moviestar”), the XML class now does the encoding for you, which brings it more in line with the E4X standard. Unfortunately, the effect of this change on Buzzword was that it would now double-encode the entities, which resulted in problems when saving Buzzword documents that contained any of these characters.

Our fix for Buzzword was to write some code to detect whether the XML class was doing the encoding, and only do the encoding ourselves when we found that the player wasn’t doing it. We deployed our fix yesterday.

By the way, you might be thinking to yourself, “Why all the fuss? It’s a beta release of the player, the download page says it’s being made available for the purpose of compatibility testing, and anyone who downloads it should be prepared to hit problems!” Unfortunately, when it comes to the Flash Player, that logic just doesn’t hold. Most users, even experienced ones, don’t think much about what version of the Flash Player they are running. If they are interested in trying out the new video experience in a beta version of the Flash Player, they’ll visit the download page at Adobe Labs, install the new player, try out some new videos, and then forget about the fact that they are running a beta player. They’ll go on about their Flash-playing business, everything will work fine for weeks or months, and then one day they’ll visit some site that uses the XML class, hit the incompatibility, and blame the site, not the player.

This is just how things are for a platform as ubiquitous and critical as the Flash Player. It has to work perfectly and transparently, and it has to be 100% backward compatible whenever possible. To Adobe’s credit, the Flash Player has a long history of excellent backward compatibility, so we were surprised by this change — it wasn’t mentioned in the release notes, even though some other non-video bugs were. We had to react quickly nonetheless.

Technorati Tags: ActionScript, Buzzword, Flash, Flex