HTML5 - MULTIPLE BUGS found and RESOLVED

Mar 24, 2014

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
Veronica Budnikas

Hi Ashley, thanks for that.

I've been in touch with John Say from support and he's had no luck with this issue, besides Articulate do not provide support for modifying output published files, which is understandable.

I might just upload here a stripped back version of my file, see if anyone can figure it out. I was really interested in the player_compiled.js solution in particular.

Thanks again, Veronica

Val G

Hi all,

In order to help to solve some iPad problems (particulary with Moodle), here is my solution for the Safari closing problem.

As denoted by Keith, when the exit command is executed (launched with a "Exit Course" trigger) the page is closed and the Safari home page is displayed.

In my project, the course is well configured and EXIT_BEHAVIOR in Configuration.js is set to SCORM_RECOMMENDED.

The course is embedded in an iframe in our LMS (Moodle 1.9.15 with custom modifications), so according to the ConcedeControl function (in API.js) the content page must be set to goodbye.html.

Further investigation lead me to the following results :
1. in Element.prototype.runAction, for "close_player" case, the second part of the "OR" statement is executed because player.lmsManager.handleClosePlayer() always returns false.
Here is the executed code that shouldn't be : (window.open("","_self",""),window.close()):(top.window.open("","_self",""),top.window.close())},10);
2. LMSClient.prototype.handleClosePlayer always returns false, even if window.lms_DoFSCommand call succeeds

Furthermore, the second part of the code in Element.prototype.runAction, for "close_player" case, happens to be an illegal call.
This bug is not pesent in modern browser on desktop computers because the call is blocked. e.g. Google Chrome shows a warning in console : "Scripts may close only the windows that were opened by it."

The following modification in player_compiled.js will enable to solve the bug :
In LMSClient.prototype.handleClosePlayer function, return true if window.lms_DoFSCommand succeeds, e.g. :
LMSClient.prototype.handleClosePlayer=function(){try{window.lms_DoFSCommand("BW_ClosePlayer"); return 1}catch(a){}return!1};

I think that removing the following part of the code will be the best workaround as the call happens to be illegal :
||setTimeout(function(){player.isCrossDomainFrame?(window.open("","_self",""),window.close()):(top.window.open("","_self",""),top.window.close())},10);

Regards
Valérian

Shivanshu Verma

Hi,

We have a SCORM developed using StoryLine 2. Everything is working absolutely fine for the desktop browser but when we are going to access the same thing in the IPAD the it is not working. We are using HTML 5 for this. Basically we have a radio button which is not working for the IPAD (IOS10).

Please find the attached palyer_Compiled.js file.

Thanks,

Shivanshu

 

Ashley Terwilliger-Pollard

Hi Shivanshu, 

Are you using the latest update of Storyline 2 Update 11? If you're still having difficulty with a radio button that isn't working, we'll want to take a look at the .story file which is the file prior to publishing. If you're using some custom Javascript to accomplish something with the radio button I'll have to defer to the community for further assistance as it's not something I'm equipped to support. 

This discussion is closed. You can start a new discussion or contact Articulate Support.