Try/Catch Blocks around Find-Calls

[psacher]

• (fix) no more "permission denied to access property API" Error when browsers cross-domain security blocks access to the target

I had the problem, that most browsers gave me "permission denied to access property API" Error when using the Scorm-Wrapper.

After some digging I found out, that the cause of this are cross-domain security properties when you open the SCO from a link that is on a different domain, than the SCO itself.

So for example:

• Create a local html-file with a link to a published/online SCO that uses the SCORM_Wrapper.
• Open the Link in a new Tab/Window
• the browser will stop when trying to access window.opener.API with "permission denied to access property API"
• the error will disappear when you close the opener Window. :/

This problem broke all my SCOs when opened from an email or different domain. The simplest solution was to wrap all find() calls in try/catch blocks. So the code runs through and the SCORM_Wrapper isn't killing my SCOs (when no API is available).

[pipwerks]

Hi pascher

Thank you, but the wrapper is designed to purposely fail if the API is not found. When a learner launches a course, they fully expect the course to be tracking their progress. If the course is NOT properly tracking their progress, it leads to big problems.

If you decide you would like the learner to be able to proceed when there is no available/functional API connection, you can handle it in your course's code via conditional statements. For example,

//Assuming you've created a variable named 'scorm_connection_active' 
//indicating API availability
if(scorm_connection_active){
    //do something with scorm
} else {
    //provide a non-scorm alternative
}

Also, SCORM relies on JavaScript, which is limited by the cross-domain security restriction you described above. I don't agree that the wrapper should be modified to silence a legitimate error/warning about cross-site scripting. If you need to support a SCORM course launched from a different domain, there are other techniques available, which fall outside the scope of the wrapper.

Sorry, but thanks for the suggestion and pull request.