SCORM 2004 Bookmarking issue with new update

[christiansen75]

My team has spent countless hours trying to find a hack, fix, or solution to what we are currently experiencing. So, without further ado....

**Scenario 1 (Issue - browser not closed)**

User 1 logs into our LMS and launches a Captivate 9 (after April /May 2016 version) HTML5 course for the 1st time and watches 5 pages. User 1 then logs out, BUT they do not close the browser. User 2 logs in and launches the same course for the 1st time and the course pops up the Bookmark option to go where the left off. The issue is that User 2 should have been taken to page 1 without a popup. All browsers act the same way.

**Scenario 2 (No Issue - browser closed)**

The same as above, but User 1 shuts down the browser forcing User 2 to open a new browser session. User 2 does not experience the bookmark issue (clean slate).

**Scenario 3 (No Issue - browser not closed or closed)**

User 1 logs into our LMS and launches a Captivate 8 or 9 (pre April  2016 version) HTML5 course for the 1st time and watches 5 pages. User 1 then logs out and either close or do not close the browser (makes no difference with older Captivate). User 2 logs in and launches the same course for the 1st time and the course launches without the bookmark popup.

**Things we have tried**

We updated our logout functionality to try to force a session destroy and to kill any cookies. This has resulted in a new session ID for every logged in user, but does nothing for the "cached" bookmarking issue. Code that we have used is below. Is there anything else that we are missing or way to enforce Captivate to not look at a local bookmarking variable or cache and look strictly at the LMS cmi.location data in the database?

*************************************

// Initialize the session.
    // If you are using session_name("something"), don't forget it now!
    session_start();

    // Unset all of the session variables.
    $_SESSION = array();

    // If it's desired to kill the session, also delete the session cookie.
    // Note: This will destroy the session, and not just the session data!
    if (ini_get("session.use_cookies")) {
        $params = session_get_cookie_params();
        setcookie(session_name(), '', time() - 42000,
            $params["path"], $params["domain"],
            $params["secure"], $params["httponly"]
    );
    }

    // Finally, destroy the session.
    session_destroy();

*************************************

[TLCMediaDesign]

Are you using a Table of Contents in the course?

[christiansen75]

We are. We do want the learner to have saved bookmarking for most courses. We have tried to turn off the self paced learning option for the TOC to see what would happen, but that still took User 2 to the "bookmarked" page from User 1, but without the normal popup option. What is disheartening to us, is that this issue has only surfaced in the latest update to Captivate 9. We have been using the same settings for our courses for the past 2-3 years and this is just now starting to happen. It definitely is not related to our LMS because no changes to the SCORM API or SCORM Player has been made in the past 9-12 months.

[Lilybiri]

Bookmarking by TOC is using local cookies or local storage (depending on output), which means it is logical what you see if multiple users are using the same system to enter the course.

[christiansen75]

I would have to disagree. SCORM courses are supposed to by default use cmi.location and/or cmi.suspend_data to get and set bookmarking to and from the LMS database through the SCORM API. These are SCORM courses and until recently, have always used bookmarking from the database as it should. Something has changed recently that is causing the users of our LMS issues when accessing training on shared computers.

[Lilybiri]

Bookmarking by TOC is disabled when you upload to a LMS. But what I wrote about cookies/local storage is correct, provided you don't use a LMS.

[christiansen75]

Thank you for your comments, but as you can see from my comments, we are using SCORM 2004 published content in an LMS AND using a TOC. Therefore, local storage should not be used and causing my issue, but somehow it is. We are looking for an answer to the issue we are experiencing.

For additional context, our development team has been using Captivate since its inception and are advanced users using advanced actions and continue to push Captivate to its limits in what it can do.

[Lilybiri]

With such expertise you have certainly already tried out the courses on SCORM Cloud? Will leave you to more experienced users.

[christiansen75]

You are correct. We have tested with SCORM Cloud as well using 2 different users accessing a course on the same realm. If you do not close the browser after logging out, the Captivate course wants to use the same local storage bookmarking for both users instead of using the database entries.

[adtiwari]

Hi David,

   I tried scenario 1. I was not able to see the issue, when self-paced learning was unchecked. We need to investigate what is going wrong at your end. I would request you if you could send me the link to your course by uploading to Scorm Cloud. Mailto: (adtiwari@adobe.com)

Thanks,
Aditya

[christiansen75]

Aditya,

I have sent an invitation from Scorm Cloud to a sample course that we are having issues with. I have tested using 2 different accounts. If I launch it with one account, log out without shutting the browser, and then login with 2nd account, I still get the bookmark popup when I shouldn’t.

The invite will be for the InfoSec Basics course.

Regards,

David

Moderator: I took out your personal credentials, too dangerous on a public forum.

[christiansen75]

Aditya,

We do want to use the self-paced learning option because we want our learners to have bookmarking and to use the TOC to help troubleshoot if they happen to miss a slide and not satisfy the completion criteria.

David

[christiansen75]

To other users of Captivate 9.0.1.320, bookmarking will no longer work properly for any user that is using a shared environment without each user shutting down the browser completely after logging out. Although we encourage users to always close their browsers after logging out of any app for security sake, it is near impossible to ensure it happens. For this scenario and for those that create training for users that share devices, be advised that a change in the Captivate code base has introduced a bug. Adobe's "solution" is to turn off bookmarking (Never Send Resume Data). This is not an option for a lot of developers because it removes the ability for users to resume where they left off (a basic SCORM function). I would advise updating to this version until Adobe fixes the issue. As of today, I was told this was not a bug, but they would "look" into it. If anyone else is experiencing this, please contact Adobe and add additional pressure.

[MidNite_Media]

I have Captivate 9.0.1.320 and, prior to this latest update, bookmarking worked the way it is intended in the SCORM environment. Since the upgrade, Captivate maintains a user's bookmark data, returning the student to where they left off (as it should). However, if that student logged out of their LMS and another logs in with their own unique credentials, Captivate resumes the previous student's bookmark. It is as if the bookmarking were cached locally somehow. I understand that if you completely shut down the browser between students, this bookmarking may be reset, but in many corporate training environments, a student logs off but leave the LMS open for the next student. It is impractical to require the training computer to completely shut down its browser between students (I understand that, for security sake, this should be a best practice - but in reality, this is not the case). This is especially true if that computer were used by other individuals (shared) such as by management or HR where other applications are required to be active all the time in another tab or window (billing, staffing, scheduling, etc.). If someone has to completely shut down the browser to eliminate the bookmarking of a previous session, then management will insist on another tool be employed for training their people. If Adobe's solution is to "shut off" the bookmarking feature, then it completely eliminates one its primary purposes such as tracking student progress on a LMS. This is unacceptable and cause for major concern! You don't mask a "bug" by making us turn off the required and requested "feature" of training departments everywhere.  I hope Adobe addresses this problem very soon and releases a "patch" or new version.... before we start migrating to Storyline or Lectora.

[RodWard]

I'm afraid I have to agree with Adobe here that this is NOT a "bug". 

If the current OS user session has not changed (i.e. the different course learners are NOT logging out of the OS and logging in as a different user) then the browser will continue to save and retrieve data from the same local storage location until its session is terminated.  That's just the way most browsers are designed to work and your specific requirements are for the browser to somehow discern that the local storage location should change according to which user is logged into the LMS.

As far as the browser knows, the OS user hasn't changed, the web server hasn't changed and the content is coming from the same web address folders, and the content files are all named exactly the same (because each user is viewing the same course), so why should it decide to use a different local storage?

So the reality is simply that unless the browser session is terminated, the browser has no reason to ditch the Local Storage data and start again just because that user happened to change their login credentials for the LMS. 

The current behaviour may not be the way you want it to work, but it makes perfect sense to me.

[christiansen75]

I would have to disagree with you 100%. I have been around eLearning since 99 working with many LMS's and content development tools. Since when does a course packaged for SCORM use local storage for bookmarking? Local storage has always been for non-SCORM publishing only. The reason for the cmi.location and cmi.suspend_data entries in a SCORM database is for bookmarking purposes. AND an LMS does know when a new user logins and therefore, can feed up the right bookmark data if the content tool works properly. All other tools that we currently use, to include Captivate (minus this last version), has always used the SCORM DB as its primary source. Thanks to this latest release, all LMS and training providers will have to deal with this issue in shared environments.

No where do I see get location from local storage from the following standard SCORM protocol.

Initialize

Get LMS values (database entries)

Set LMS values (database entries)

Commit

Finish

Exit

[RodWard]

If you have the ability to run client-side JavaScript code when the user logs OUT of the LMS, try running this line of code to see if it fixes the issue:

sessionStorage.clear();

[christiansen75]

We do have the ability as we have our own LMS and access to its code. I do feel for users that have 3rd party LMS's and cannot. I will have my team clear session storage through javascript to see if it works better than our session destroy through PHP that we have already tried.

[christiansen75]

Still no luck!

We tried localStorage.clear() and sessionStorage.clear() after logging out. Neither is wiping out the bookmark from the previous user resulting in a faulty bookmarking experience.

Thanks for the input.

[christiansen75]

As a follow up, our LMS and other LMS's create a session when a user logs in. On log out, we are destroying that session. But, what we are noticing is that Captivate creates a different unnamed cookie when it launches a course. This cookie has data that looks like "41/1/0,1,2/0,1,//2". This is the cookie that is remaining behind after the LMS logs out and the browser is not closed. If we can determine how to destroy this cookie and its data, we can circumvent the bookmarking issues.

[RodWard]

Maybe this will help:

javascript - sessionStorage.clear() not working - Stack Overflow

[christiansen75]

I tried that exact code earlier to no avail. That is when I started looking into what cookies Captivate was creating and found the nameless one that the player is using for bookmarking. If I can figure out how to destroy that one, I think we can find a hack to the issue. It is more difficult because it does not have a name. Even when using document.cookie, the nameless cookie won't show.

[TLCMediaDesign]

The cookie you are describing is in fact the self-paced learning cookie associated with the table of contents.

I've not experienced the issue, but a great tool for comparing files/folders is Beyond Compare. You could point it to the course that works and the one that doesn't and see the difference. This would help you find that actual piece of code that is causing the issue.

[christiansen75]

Well, during our troubleshooting, we found that Captivate is looking for local storage 1st and then at the database 2nd for the location. Since this does not work well for shared environments, we pursued wiping out the cookie that it is creating. Hoping to do this on a global scale failed because we could not call up or find the cookie from the LMS itself. The cookie could only be found from within the course content. The fix?

We created a custom JS file that overrode the existing window.DoCPExit function in CPM.js file. We added document.cookie = "" + "=;expires=Thu, 01 Jan 1970 00:00:01 GMT;"; as the 1st command before firing off any of the exit functions. This took care of the cookie when using the internal exit button. For the browser button, we created an onunload function in the index_scorm.html file that used document.cookie = "" + "=;expires=Thu, 01 Jan 1970 00:00:01 GMT;"; to delete the cookie. Now, both the exit button and browser exit button clear the cookie.

After testing, Chrome is the only browser thus far that this will not work with. Chrome is unable to find cookies that have no name, therefore, it cannot delete what it cannot find. We have tried the js.cookie and jquery.cookie libraries too and that also fails on Chrome. On to the drawing board.

[Michael27983093gma1]

I know this is quite old, but I have a solution to finding nameless cookies.  It can be done in Chrome (at least recent versions) by first finding the index of the nameless cookie (not too much trouble), then applying the epoch expiration date as if the value were the name.  It looks like this:

// Get an iterable list of cookies
var cookiesobj = Object.fromEntries(document.cookie.split('; ').map(c => c.split('=')));
// set up a receiver variable
var nameless = false;
Object.keys(cookiesobj).forEach((name)=>{
// cookie without name becomes name without value, so we test for an undefined value
    if(cookiesobj[name] === undefined) {
        nameless = name; 
    }
});
// If a nameless cookie exists, delete it
if(nameless !== false) {
    document.cookie = name+expires=Thu, 01 Jan 1970 00:00:00 GMT";
}

I haven't yet implemented this within my LMS, but I have tested against a module with self-paced enabled - and was able to delete the cookie.