HTML5 - MULTIPLE BUGS found and RESOLVED

Hi all.

I've been tasked with deploying Storyline to iPads 'no matter what'. So, needless to say I've been in and out of every aspect of the HTML5 output and found numerous bugs and issues. Fortunately, I've been able to overcome most and will list them here.

The primary means for providing temporary relief from these bugs was to edit the player_compiled.js file included in the published package when publishing for HTML5. The player_compiled.js file is a compiled, or minimized, version of the original working file shipped out with Storyline. It is basically the heart of the HTML5 version of the Storyline content and serves to replicate the functions of the Flash version. Unfortunately, the compiled version is not easy to read but can be navigated with the right tools and can be edited where necessary.

For a given version or release of Storyline this file is the same. So, applying patches or fixes to known bugs is simply a process of replacing the published player_compiled.js file with the modified version. **Just be sure you're using the same release of Storyline. You can check to make sure the player_compiled.js file matches by checking the first line in the file where a 'buildNumber' is defined along with a 'buildDate'. Those two should match the modified version. If they don't then you should not replace the file as it will assuredly cause unexpected issues.

Now, to get down to it.

Below are the known issues found in the player_compiled.js file where fixes were applied as well as their symptoms while playing the content.

  • When viewed in Safari Mobile on the iPad, CPU usage becomes abnormally high sometimes reaching levels beyond 100%. This issue is due to a programming flaw that triggers animation events excessively. This is due to the use of both setInterval animation calls AND using the window.requestAnimFrame function. These methods are somewhat interchangeable but should not be used in conjunction with one another. I chose to use only the setInterval method since it actually uses less resources and provides comparable quality. (Addressed starting at line 18489 & 18729 of the provided player_compiled.js file.)
  • When resuming on Safari Mobile, previously viewed slides are not restored to the player. What makes this more interesting is that the previously viewed slides (from the most recent session) are in fact reflected in the Outline as viewed but when closing and returning are not subsequently restored. This is due to the fact that on resume the player must not only reflect the previously viewed slides in the Outline but must also add those slides to an array of slides where previously viewed slides are tracked. This does not occur. Therefore slides viewed in a previous session are not saved as being viewed in subsequent sessions. The fix for this was to simply make an additional call when restoring the state of viewed slides. This was done by adding 'player.restoreViewedState(j);' to the function 'Storyline.prototype.updateFromCompactData'. (Addressed starting at line 5811 of the provided player_compiled.js file.)
  • When resuming on Safari Mobile, previously viewed slides are not displayed as viewed in the Outline. This issue occurs when some presentations, on restoration, attempt to rebuild the Outline or 'slideList' as referenced in the code. The viewed states are initially restored but subsequently overwritten. I includes some code that inhibits rebuilding of the Outline if it has previously been built. This preserves the viewed states of the slides while having no negative impact on the presentation. (Addressed starting at line 12047 of the provided player_compiled.js file.)
  • When resuming on Safari Mobile, all progress seems to be lost. This particular issue occurs as a result of an error being thrown when attempting to run the function 'Storyline.prototype.updateFromCompactData'. In some presentations, an error will occur causing the function to exit early and not restore any previously viewed slides to a viewed state. I fixed this by wrapping a 'try - catch' around the section where the error occurs. This does not prevent the error from occurring but does allow the function to complete, thereby properly restoring progress including previously viewed slides and last slide viewed. (Addressed starting at line 5779 of the provided player_compiled.js file.)
  • When resuming on Safari Mobile, boolean variables may not restore to their previously saved state. This was by far one of the most interesting and challenging fixes. Because of the way Storyline saves suspend data and variable states, this issues was difficult to detect and fix. However, I did come up with a fix that ensures all boolean variables, including those with a default to TRUE, are restored properly. Storyline's player logic does not inherently provide restoration of boolean variables whose default value is TRUE but was previously set to FALSE. It will only restore variable from their default value to TRUE. This fix addresses the shortcoming and properly handles ALL boolean variable and their suspended values. (Addressed starting at line 4744 of the provided player_compiled.js file.)

I've attached the modified player_compiled.js file for use at your own risk. Simply replace the one inside your published files located within the 'mobile' directory. **Make sure that you verify the build number and date against your published file.

Provided build number and date:

var buildNumber = 60;

var buildDate = "20140121 13:39";

Now, here's where I need your help. Please evaluate my findings and remedies. Pass on your feeling to the Articulate team in how important it is that these issues are addressed in a timely manner. Now that the issues have been identified and remedies found, there's really no reason why they can't be resolved in the next release. It is not my desire to rely on and maintain a modified version of their player javascript file but unfortunately necessary in order to see implementation on the iPad in a traditional LMS environment.

Thank you.

Jamie Smith

*UPDATE*

The Storyline version used for this development and testing was Update 5 - 1401.2415.

31 Replies
Jamie Smith

We actually use an outsourced vendor with their own in-house SCORM LMS. However, we have been using Moodle as an in-house LMS for development, testing, and production for many years.

If you are a user of Moodle and are interested in deploying to the iPad in HTML5 let me know. I had to make some changes to the SCORM module to get it to display properly. Moodle's SCORM player always wraps the content in a container using a frame which prohibits the proper display of content on the iPad and does not handle device orientation changes well. I'd be glad to share my changes which amount to forcing the content to pop up into its own native window and uses the player window to capture LMS  communications. Now that I think of it, I'll probably put together a separate post addressing that very thing since many of you are using Moodle and would like to target iPads.

- Jamie

Dan Marsden

Just quickly jumping in here to mention that we have improved the display for mobile devices in Moodle 2.6 but there are 2 outstanding issues at the moment that should get fixed within the next week or so.

The main one is https://tracker.moodle.org/browse/MDL-43011 - it fixes a range of display issues with content in the new window and removes all the extraneous Moodle theme formatting stuff to allow the SCORM package to use the full space available.

the other one currently open is: https://tracker.moodle.org/browse/MDL-44738

if there are still issues after those 2 bug fixes land in core I'd be interested to hear from users who can provide a scorm package and full information on how to reproduce.

Keith Williams

Hi Jamie,

I am impressed with the amount of work you are doing finding bugs and attempting fixes for them. I know that these fixes are for Articulate Storyline - but I am wondering if you are also looking into fixes for Articulate Studio 13?

Currently I am having a lot of problems trying to get the published content (SCORM) working as expected from Articulate Studio 13, when played on iPad. It seems that no matter what I try and do, if I include an Exit tab in the Articulate Player, it will only work on a PC. Clicking Exit closes the content properly (on a PC), and then I can Exit the Activity and return back to the main topic page in Moodle.

However, on an iPad (using Mobile Safari iOS 7.1), if I click the Exit tab in the Articulate Studio 13 Player, I come out of Moodle all together, and end up on a blank safari browser page.... (note when publishing I include the option for HTML5 (but not mobile player), as I can't get that to work either)...

We are currently using Moodle 1.9.19 (and I know perhaps that other people will say 'what?' why haven't you upgraded to Moodle 2.6 etc etc...) the truth is we are flat out trying to create content, and to move to Moodle 2.6 would mean a server upgrade, and lots of work involved (as we have a fairly customized version of Moodle at the moment).

We have been able to get Exit to work on iPad before (using Articulate Storyline content), but so far have not been able to make that work with Articulate Studio 13.

I would be most grateful if you can 'shed any light' on any of this Jamie, or, indeed have experienced similar problems when publishing from Articulate Studio 13 (for iPad)?

Kind regards,

-Keith

Dan Marsden

you are really fighting a losing battle trying to get Moodle 1.9 working with an iPad.

Moodle 1.9 was first released on 3 March 2008

The first iPad was released on 3 April 2010
Support for general bug fixes in 1.9.x ended June 2011

some bug fixes related to mobile device usage landed in Moodle 1.9 before June 2011 but not very many.

If you have a reliance on mobile device usage you really shouldn't be wasting your time with 1.9 - I can't encourage you enough to spend some time/money or effort to upgrade your site asap.

Jamie Smith

Dan,

Thanks for your input. We're still on Moodle 2.4.x right now. Since our work on implementing Tin Can to host and track Storyline in the Mobile Player, we have not spent the resources on upgrading. So, it's quite possible the SCORM player has evolved to a point where our modifications are no longer necessary.

Keith,

I understand your circumstances as we are still on Moodle 1.9.x in a production environment due to the massive modifications and integration accomplished years ago. Our operation will cease to exist at the end of the year. So, there's been no effort dedicated to migrating forward. I have not had any experience with the Studio 13 and HTML5 output. So, unfortunately I can't help with any experience in that area. I have noticed that the Exit trigger which should be the same basic function as tapping the Exit button on the Player provides varying results based on the LMS host. Moodle, using the player wrapper in version 1.9.x, would assuredly cause some unexpected results. Are you setting the SCORM up to play  in a new/popup window? Or, are you having it play in the same window? If you're playing it in the same window, the window.close event sent by the Articulate content could be making it's way up to the Moodle player window and closing it all together. 

Ashley Terwilliger-Pollard

Hi Jamie,

Thanks for sharing those here, and I checked in to see that you're also working on a case (# 00391083 for my reference) with Christine. She'll be testing out all of the above mentioned items further and then will share with our QA team if determined to match existing issues or found to be new bugs. 

Keith Williams

Hi Jamie

Thank you for taking the time to reply, and for your advice. I appreciate the fact that you have not had any experience with the Articulate Studio 13 and its HTML5 output, and have been focusing on Articulate Storyline as your development environment. 

Never the less, you made an interesting comment, by pointing out that you have noticed that in your experience the Exit trigger (which should be the same basic function as tapping the Exit button on the Player) provides varying results based on the LMS host.

Although you suggest that Moodle, (using the player wrapper in version 1.9.x), would assuredly cause some unexpected results - it has been my experience that Articulate Storyline scorm content seemed to work fine on iPad or PC, and responded well to the Exit tab (on either platform). However, the Exit tab (when used on the Articulate Studio 13 content when played in Moodle) on iPad causes the problem of coming all the way out of Moodle and back to a blank safari browser window...

We do not set the SCORM up to play  in a new/popup window, it is played in the same window within Moodle.

I have alerted my developer to what you suggest he could investigate.... to see if by playing it in the same window, the window.close event sent by the Articulate Studio 13 content may be making it's way up to the Moodle player window and closing it all together. 

I will let you know what he finds out about that, OK?

Dan,

Thanks for your input. I have suggested that my developer perhaps tries to create a sandpit version of Moodle 2.4 or later, and we test the problematic Articulate content on iPad and PC from within that. However, I am not sure if he is able to create such an environment quickly.... but we will see if he thinks that is possible. Do you know if there is somewhere else I could test my problematic Articulate Studio 13 content in such a sandpit version of Moodle? If you have such an environment yourself could you allow me to test it there?

Keith Williams

Hi dan,

I tried uploading my test file to the site http://school.demo.moodle.net (logged in as admin). I used their sandbox environment. It said it was using the latest version of Moodle - so would that have been 2.6?

I was unsure how to get rid of all the blocks like navigation, administration etc etc... which occupied most of the real estate of the screen.... when trying to upload and then present my scorm content as a topic. However I managed to collapse some of the blocks, and was able to play the content on the PC. I could Exit from the courses (using the Exit tab in the Player window).

However, my experience trying to use that site on an iPad was awful! Again, the blocks were everywhere occupying all of the screen I tried moving them around but couldn't get them to a position that wouldn't obscure my player window.

I was able to eventually launch the content, But I couldn't get it to display correctly, as most of the content was off to the right of the screen. I tried using various gestures to drag the Player content window over so I could see the next and Prev navigation buttons, and to get to the Exit tab (at the top right of the Player window). Eventually, I was able to do that - but it was not very easy to do it. I then pressed the Exit tab, and Moodle simply closed itself and left me with a blank safari browser window.

So, several issues with that - and I still am thinking that the Exit tab behaviour just does not work in the Articulate Studio 13 Player window when viewed on an iPad using Mobile safari under iOS 7.1.

Any other suggestions I could try, Dan?

Kind regards,

-Keith

Dan Marsden

strange that the demo sites aren't optimised for mobile device usage... I'd recommend trying the "new window" option when creating the scorm - theoretically it should then just close the current window and return you to the previously open window. 

if that doesn't work... you could try contracting with a Moodle Partner for further help (disclosure - I work for the Moodle Partner Catalyst IT and we have offices in UK, AU, NZ)

Jamie Smith

Hi Keith.

I tried using the site mentioned. I experienced similar issues to what we have had with our 2.4.x version. Basically, the New Window option still wraps the content in a container of frames with extraneous elements that do not allow full screen viewing on the iPad. The Storyline player for HTML5 is designed to run in its own window without a wrapper of frames. It may be possible to do with adequate results. However, the SCORM API is designed to support communication as a pure popup and works quite well in Safari. It does not however work in other iPad browsers such as Chrome since there is evidently some restrictions on Web view to Web view communications in these browsers.

I have modified my SCORM container to launch the Storyline player into it's own native window while using the Moodle SCORM player page as the SCORM API host. If you've used SCORM Cloud at all for testing, it works much in the same way where the Moodle player page displays a message to indicate the content is launched in a new window. The Moodle player page checks to see if the content window is open ever so often (2 seconds) and will automatically redirect back to the course page when the content is closed after a short delay to allow completion of any requests being made through the API to the LMS. A message appears during this time indicating that progress is being saved and the user will be redirected automatically to the course page.

Another feature implemented is the 'blocked popup' feature. If the Moodle player page cannot launch the Storyline popup window, a message will appear requesting the user turn off the popup blocker or allow popups for the website. A button is also displayed to manually launch the popup window.

If you are interested in the code required to make it work, I can provide it. It is designed around 2.4.x but should adapt quickly to later versions. You may even find that it could work quite well in Moodle 1.9.x if applied properly.

Jamie Smith

I've created a new discussion thread, http://community.articulate.com/forums/p/46717/251304.aspx#251304, to use in posting my Moodle SCORM modifications that allow a 'New window (simple)' option when launching SCORM packages. This method strongly emulates the SCORM Cloud behavior and ensure your Articulate content will launch in its own native window allowing proper display and adjustment to orientation changes on the iPad.

The Moodle 1.9.19 version of the modifications are complete and uploaded. I'll post the Moodle 2.6.x modifications soon.

*UPDATE*

The Moodle 2.6.x version is now available.

Julie Applebury

Hello,

I have searched and searched for info regarding HTML5 with Mobile Safari and SCORM Cloud.  I am CONSTANTLY dumped when I run my courses on my iPad mini under these conditions.   Some of the bugs mentioned in Jamies list seem to be occuring (losing track of the pages viewed, progress lost)....however, his js file did not seem to help me. 

I constantly get this message: This site is attempting to open a pop-up window.  Block Allow

Occasionally safari closes down completely (but this is not so frequent).

I submitted a problem report a while back, but really didn't get any information or help with this.  I am so surprised that I don't find lots of information about this, since it happens so consistently with all my courses.

Am I missing something.  Please HELP!!

Julie

Garry Nordenstam

You can turn Block Pop-Ups ON or OFF in the iPad Setttings > Safari > Block Pop-Ups Option.  You can't set this for one site, the option is a general setting and applies to all sites.

With regards to getting dumped out when running HTML5 and SCORM Cloud, I have run into the same issues. It appears to be a memory management and memory allocation issue by the iPad and Mobile Safari combined with the many SCORM communication calls being made.

--Garry

Garry Nordenstam

Here's some information regarding the limitations of Mobile Safari browser from the Apple Developer site (there is also a view that iOS7 places imposes even more reduced memory limitations) ...

Your webpage performing well on the desktop is no guarantee that it will perform well on iOS. Keep in mind that iOS uses EDGE (lower bandwidth, higher latency), 3G (higher bandwidth, higher latency), and Wi-Fi (higher bandwidth, lower latency) to connect to the Internet. Therefore, you need to minimize the size of your webpage. Including unused or unnecessary images, CSS, and JavaScript in your webpages adversely affects your site’s performance on iOS.

Because of the memory available on iOS, there are limits on the number of resources it can process:

  • The maximum size for decoded GIF, PNG, and TIFF images is 3 megapixels for devices with less than 256 MB RAM and 5 megapixels for devices with greater or equal than 256 MB RAM.

    That is, ensure that width * height ≤ 3 * 1024 * 1024 for devices with less than 256 MB RAM. Note that the decoded size is far larger than the encoded size of an image.

  • The maximum decoded image size for JPEG is 32 megapixels using subsampling.

    JPEG images can be up to 32 megapixels due to subsampling, which allows JPEG images to decode to a size that has one sixteenth the number of pixels. JPEG images larger than 2 megapixels are subsampled—that is, decoded to a reduced size. JPEG subsampling allows the user to view images from the latest digital cameras.

  • The maximum size for a canvas element is 3 megapixels for devices with less than 256 MB RAM and 5 megapixels for devices with greater or equal than 256 MB RAM.

    The height and width of a canvas object is 150 x 300 pixels if not specified.

  • JavaScript execution time is limited to 10 seconds for each top-level entry point.

    If your script executes for more than 10 seconds, Safari on iOS stops executing the script at a random place in your code, so unintended consequences may result.

    This limit is imposed because JavaScript execution may cause the main thread to block, so when scripts are running, the user is not able to interact with the webpage.

    See the Safari Web Inspector Guide for how to debug JavaScript on iOS.

  • The maximum number of documents that can be open at once is eight on iPhone and nine on iPad.

Garry Nordenstam

Julie Applebury said:

Garry,

Thanks so much.   I'll study this.

It looks like my next step is to check my graphics...make sure they are as small as possible.  Given that everything else is controlled by Storyline, I'm thinking that is the only real adjustment I can make.  Am I comprehending?

Julie

Graphic size is a good place to start.

--Garry

Veronica Budnikas

Hi all,

This is amazing work from Jamie, thank you!

I would be interested to know whether, 10 months later, anyone has been able to fix this particular issue:

"When resuming on Safari Mobile, boolean variables may not restore to their previously saved state. This was by far one of the most interesting and challenging fixes. Because of the way Storyline saves suspend data and variable states, this issues was difficult to detect and fix. However, I did come up with a fix that ensures all boolean variables, including those with a default to TRUE, are restored properly. Storyline's player logic does not inherently provide restoration of boolean variables whose default value is TRUE but was previously set to FALSE. It will only restore variable from their default value to TRUE. This fix addresses the shortcoming and properly handles ALL boolean variable and their suspended values. (Addressed starting at line 4744 of the provided player_compiled.js file.)"

I am now on SL2, so this file does not apply to SL2.

Thanks to anyone who can assist, cheers,,

Veronica

Ashley Terwilliger-Pollard

Hi Veronica,

In regards to the issue Jamie mentioned with the boolean variables, that is still with our QA team for review and I don't have any additional updates to share.

You mentioned you're using Storyline 2, and his issue was with Storyline 1. Are you having the same difficulty in Storyline 2? If so, do you have a sample file we could take a look at?