Jay Harris is Cpt. LoadTest

“He’s a big pig. You can be a big pig, too.” ~Timon

Turns out that Flash isn’t the murderous killer with the 9-inch chef’s knife. It’s just a big pig. Flash, within this Scorm course, was passing Scorm data to an external JavaScript function. JS was opening an ActiveX XmlHttpRequest object to send the Scorm data to the service via a WebService call (think AJAX). However, Flash was requiring that this be a synchronous call (so much for AJAX). W3C regulates [Hypertext Transfer Protocol — HTTP/1.1 RFC 2616 Section 8.1.4] that “a single-user client should not maintain more than 2 connections with any server or proxy.” Flash is busy downloading external assets, so both connections were taken, and it then says “go and make a synchronous XML call.” XmlHttpRequest object doesn’t like making a synchronous call when there are no available connections to the server; it bugs out and the browser freezes.

Hopefully things will be better with Internet Explorer 7. It is slated to no longer use the ActiveX version of XmlHttpRequest object, but rather the XmlRequest object that Mozilla uses. Perhaps this one will handle itself a little better.

Flash movies with multiple external assets can cause the browser to lock up if external Flash assets (videos, images, voice-overs, etc, that are not stored within the SWF) are unmanaged or managed improperly. I’ll use a Scorm-compliant course as an example; the example course navigates from screen using inline Back and Next buttons, and each screen loads unique external animation and voice-over to deliver the lesson topic.

The browser freezes when:
• The user skips lesson information by clicking “Next” in rapid succession (assets are not downloaded to local cache before progressing to next screen)
• The user re-enters a course for which they have a previously saved Scorm-bookmark, and quickly navigate to where they left off, either by menu navigation or by rapidly clicking “Next” (assets are not downloaded to local cache before progressing to next screen)
• The user rapidly clicks “Back” through screens that they did not experience in their entirety (assets were not fully downloaded and stored in local cache)
• The user navigates to other areas of the course through menu navigation before they have experienced the current screen in its entirety (assets are not downloaded to local cache before proceeding)
  The recurrence is exacerbated by:
  • Slower connection speeds (it takes longer to download a single asset)
  • Larger file sizes on external Flash assets (it takes longer to download a single asset)
  • Having multiple external Flash assets on a single screen (it takes longer to download a single asset)

The course does not freeze when:
• The user linearly navigates through the course, experiencing each screen in its entirety before progressing to the next screen or area. (assets are allowed to fully download and store in local cache before proceeding to next screen)
• The user skips lesson information by clicking “Next” in rapid succession through courses that they have previously visited in this session and experienced in their entirety (assets are already in local cache)
• The user rapidly clicks “Back” through screens that they did experience in their entirety in this session (assets are already in local cache)
• The user navigates to other areas of the course through menu navigation after they have experienced the current screen in its entirety (assets are allowed to fully download and store in local cache before proceeding to next screen)

When a user navigates from Screen #1 to Screen #2, any outstanding, incomplete asset downloads from Screen #1 should be stopped before beginning Screen #2 asset downloads. Failure to do so may cause the browser’s request queue to overflow, and freeze the browser window.

Such is the case when assets are not properly managed: when a user navigates from Screen #1 to Screen #2, the Screen #1 assets continue to download with the #2 assets. Likewise, when the user navigates from Screen #2 to Screen #3, assets from Screens #1, #2, and #3 are all downloading. When Flash is downloading enough concurrent assets, a request queue overflows, freezing the browser.

IMPORTANT: Users clicking Next rapidly is not the only cause of this issue. Rapid Next is just the easiest way to recreate it. The important point is that users are clicking next faster than Flash can download the other assets. In other words, navigation is adding assets to the download queue faster than Flash can download them, and the queue is filling up.

A sample browser-freezing scenario:
(Ex: Unmanaged external assets. User rapidly clicks next.)
1. User launches course. Flash switches to Screen #1 and begins downloading Screen #1 voice-over and Screen #1 animation. If applicable: HTML, Non-flash images, stylesheets, etc all download.
   (2 assets downloading)
2. User quickly hits Next. Flash switches to Screen #2. Does not sever Screen #1 asset connections. Begins downloading Screen #2 VO and Animation. If applicable: HTML, Non-flash images, stylesheets, etc all download, but do so slower.
   (4 assets downloading)
3. User quickly hits Next. Flash switches to Screen #3. Does not sever Screen #2 asset connections. Begins downloading Screen #3 VO and Animation. If applicable: HTML, Non-flash images, stylesheets, etc all download, but do so slower.
   (6 assets downloading)
4. …
5. User repeatedly hits Next. Flash navigates through appropriate screens, downloading new assets but never severing previous asset connections.
   (Many assets downloading)
• Browser request queue overflow.
• If applicable: HTML, non-flash images, stylesheets, etc, DO NOT download.
• Browser freezes.

Under a non-freezing scenario:
(Ex: Managed external assets and/or User proceeds slowly through course)
1. User launches course. Flash switches to Screen #1 and begins downloading Screen #1 voice-over and Screen #1 animation. If applicable: HTML, Non-flash images, stylesheets, etc all download with no degradation.
   (2 assets downloading)
2. User hits Next. Flash switches to Screen #2. Severs Screen #1 asset connections. Begins downloading Screen #2 VO and Animation. If applicable: HTML, Non-flash images, stylesheets, etc all download with no degradation.
   (2 assets downloading)
3. User hits Next. Flash switches to Screen #3. Severs Screen #2 asset connections. Begins downloading Screen #3 VO and Animation. If applicable: HTML, Non-flash images, stylesheets, etc all download with no degradation.
   (2 assets downloading)
4. …
5. User hits Next. Flash navigates through appropriate screens, downloading new assets. Previous asset connections are severed.
   (2 assets downloading)
• No Browser request queue overflow occurs

Example Code that causes the problem:
narrator = createClassObject(MediaDisplay, “My_VoiceOver”);
narrator.setMedia(”/Assets/MyVoiceOver.mp3″, “MP3″);

// … code omitted …
// … do some stuff …
// … do some stuff …
// … code omitted …

// commented out code
// destroyObject(”My_VoiceOver”);

The code above creates a new object that loads and plays an MP3. However, (because the line of code is commented out) the object is never destroyed and continues to download. If this function is called repeatedly, each time against a different voice-over file, the queue will overflow and the browser will freeze. The same will occur wherever destroyObject (or similar command) is not called.
To fix the code in the above scenario, destroyObject must be uncommented, allowing the object to be destroyed, thus stopping the MP3 download.

Note: This is not the only code scenario that would create this browser-freezing problem. There are many possible commands and variations.