Jay Harris is Cpt. LoadTest

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.