Warning: Do not use Adobe Captivate 9 in a CDN environment!

If you are planning on publishing content from Adobe Captivate 9 to a website or LMS (Learning Management System) using CDN (Content Distribution Network) then you should pay close attention to the information in this post.

At my regular day job we have an enterprise grade LMS from where we distribute course content to clients around the world. The LMS utilizes a CDN to provide end-users with  high availability and high performance when they are viewing course content. This works perfectly well and we have more than 250 courses running in this environment that were published from Adobe Captivate 7 (We skipped Captivate 8 altogether).

When Adobe Captivate 9 was released we decided to jump on the wagon right away and converted 8 projects we were working on to Adobe Captivate 9 and continued development. Prior to taking the leap we did a test publish of a course and uploaded it to our LMS. It worked perfectly fine when we tested the SWF and HTML5 output from a computer.

After weeks of development we had a couple of the courses ready and uploaded them to the LMS. We tested them and also whipped out an iPad to do the final QC. We had checked the course on an iPad while developing it, but doing development we test it on a local server – not from the LMS. We were rather surprised when the course didn’t work on the iPad when running it from the LMS – the course was stuck on the first slide of the course and displayed “loading” constantly. We then tried running the HMTL5 output on a computer using Google Chrome and here it worked just fine.

At first we thought it was a problem with the LMS so we tried uploading the SCORM package to SCORM Cloud and tested the course – it worked perfectly fine from that LMS. We also tried a couple of our other LMS’s and here the course worked fine as well. At this time we were certain that it was our main LMS that had a problem. That theory held until we tried another LMS which utilizes CDN – here the course didn’t work either.

After a bit more digging around we found out that the problem is actually with the content that Adobe Captivate 9 creates (the bug exists in Captivate 8 as well).

The problem was caused by the “mouse.mp3” file not being loaded and this caused the entire course to get stuck on the first screen. The reason why the “mouse.mp3” file wasn’t loaded is that there is an error in the XHR (Ajax) request coming from the course to load the file.  It does not send the X-Requested-With:XMLHttpRequest header information as it should which causes problem for sites that processes cross domain requests as it breaks the CORS request (Cross-Origin Resource Sharing). If the course doesn’t send the proper headers when requesting files, the server does not know it needs to send a range request and stream the content which causes the course to not work in CDN environments.

Normally headers such as X-Requested-With:XMLHttpRequest is added automatically by libraries such as jQuery, which Adobe Captivate also uses so why does it not work with “mouse.mp3”?

Well there can be two explanations (we haven’t found out which one is the correct one yet):

1) The file “mouse.mp3” is requested by some different code which are not sending the proper headers and totally bypassing jQuery.

2) Adobe Captivate uses jQuery 1.6.1, which was released in May 2011. Yes.. May 2011 – Adobe Captivate 9 uses a library that is 5½ years old and have had 23 subsequent releases of new versions The most current (as of Sep-2015) jQuery version is 1.11.3 or 2.1.4 for the library without support for IE 6,7 and 8.

So if the problem is number 1, the fix should be relatively simply for Adobe. Simply identify the codebase that loads the mouse.mp3 and switch it to use the jQuery library instead so the proper headers are added.

If the problem is number 2 then the fix probably isn’t that easy for Adobe. jQuery 1.6.1 is what makes your Captivate HTML5 content work and is most likely deeply integrated into Captivate.

Another question that you can ask yourself is why is it that if you animate 3 circles using effects in Captivate it plays perfectly well on a computer, but on an iPad Air2 you get serious lags and timing issues? After all you can easily play 3d racing games on an iPad so why can’t Adobe Captivate animate three circles without lagging up? One explanation could very well be that Adobe Captivate 9 uses a 5½ year old library to display HTML5 content – A lot of things have happened in 5½ years and in 23 new releases of jQuery with bug fixes, upgrades, optimizations and not to forget – fixes of security vulnerabilities (including a Cross-site scripting (XSS) vulnerability in jQuery 1.6.1!)

My guess is that the problem is caused by number 1 – some rogue code requesting the mouse.mp3 file without utilizing jQuery and thus not sending the proper headers. However I am also 110% convinced that the fact that Adobe Captivate 9 uses a 5½ year old jQuery library is causing more pain than gain.

Unfortunately you can’t do anything about this yourself. You cannot modify the code so if you are planning on delivering Adobe Captivate 8 or 9 content to HTML5 for iOS devices and you are using CDN technology, then you are at the mercy of Adobe and have to wait for them to fix the problem.

I highly encourage you to submit a bug report to Adobe here – http://www.adobe.com/products/wishform.html  – so they know that this is a big problem. After all you will see more and more systems, servers, LMS’s etc. utilizing CDN’s in the future so it might as well get fixed sooner rather than later.