This post is for SCORM techies only. While reviewing web server logs I ran across an odd bug. Many people have run my cross-domain demo at
http://www.ostyn.com/standardswork/xdomain/remotecontentdemo.htm. In that demo, content from 3 different servers appears on the same page. Content from two of those servers can communicate in spite of cross-scripting security blocks in the browsers, because it is actually served through reverse proxy that enforces security. The second demo on the page uses a test wrapper (which can function as a SCO) that acts as runtime environment for a demo SCO. When it is inialized, the test wrapper reads a launch parameter that specifies the SCO to launch. The wrapper and the SCO come from different domains, but both are accessed through the same reverse proxy so they can talk to each other. However they can't talk to the demo page since that one comes from yet another server. Now the bug: The log showed that for some people the SCO that was supposed to be loaded through the reverse proxy did not get downloaded. To make a long story short, I finally tracked that down to a cross-scripting "feature" of FireFox that caused the test wrapper initialization script to die before it could load the SCO.
The "wrapper" in the demo tries to discover an API object because it doesn't know whether it is running standalone or in a LMS. The discovery algorithm fails in FireFox because of an unexpected side effect of the FireFox scripting security implementation, and the rest of the initialization fails silently. Once this could be diagnosed, it was a relatively simple matter to fix the API discovery script to handle FireFox gracefully. This is documented in a new scripting resource document at
http://www.ostyn.com/standards/scorm/samples/api_discovery_ff_issue.htm
