Blogature

Whew. I’m tempted to come up with a shorter title for this post, but I think “Flash-to-JavaScript communication with a streaming HTTP connection in Internet Explorer” appropriately and specifically defines the problem (which I’m sure people run into all the time). I digress.

If you’re interested in the Hot New AJAX Web 2.0 Ethernet Cyber Monorail Page Technology, you’ve probably heard of using long-lived HTTP connections for server-to-client communication in web applications. The technique (sometimes called “Comet” or “server-push”) is based on the idea that browsers will execute complete chunks of JavaScript as they’re received rather than waiting for the connection to close. The process begins when a client requests a resource (we’ll call it /stream). The server begins to respond to the request, sending along all of the appropriate headers, but then keeps the connection open (as opposed to notifying the client that it’s done sending content). As things happen during the application session, the server writes fully-formed script tags to the open connection in order to send notifications to the client.

The advantages to this approach have been discussed in detail elsewhere, but the biggest one (particularly for Thinkature) is that it’s a very low-latency way to communicate. Were it not for the server-to-client stream, the client would have to poll the server at regular intervals to find out if anything new had happened. The process of polling introduces some inherent latency, and it also adds to overhead through opening and closing connections and complicates synchronization (there’s no guarantee that messages will arrive in the order you expect them to).

One of the big problems with this approach is that it’s not yet well-understood. Strange problems pop up that nobody’s run into before, and there’s nowhere to turn for help. In adding voice chat to Thinkature, we ran into one of those problems. Our voice chat client is a small Flash movie that’s embedded in the Thinkature workspace. It notifies the workspace of events (user joins voice chat, begins speaking, stops speaking, etc.) via an ActionScript-to-JavaScript call. We discovered that whenever the voice chat client sent a message to the workspace server, Internet Explorer (and only IE — all other browsers were fine) would drop its streaming connection to the server. This was, obviously, unacceptable.

Flash-to-JavaScript communication works most reliably by calling the ActionScript getURL method with a javascript: link. After a lot of unsuccessful experiments, I hypothesized that IE treats javascript: URLs the same way as links to other pages: by preparing to leave the current page and closing any open connections. I’m not sure that’s strictly true, but I get the feeling that it’s something along those lines. In any event, I wondered if sending the JavaScript “impulse” to a frame inside the main document would prevent IE from “navigating away” from the workspace and dropping the streaming connection.

I created an invisible frame inside of the workspace and began sending ActionScript-to-JavaScript messages to that frame instead of to the main frame. Instead of calling “handleEvent(...)“, for example, I would call “parent.handleEvent(...).” To my pleasant surprise, it worked. A diagram of the “bad” approach and the “good” approach is included below.

So, in short, the message here is that sending Flash-to-JavaScript messages directly to the main frame of a streaming application under Internet Explorer causes a loss of stream connectivity. The workaround we use for Thinkature is to embed a “dummy” frame in the main document that routes the messages safely to the main frame.

Again: whew.