January 12, 2020 at 11:30 am #436977
Brian RoemerMember6 pts@broeme
Good morning everyone…I hope 2020 has started off well for everyone in the community!
Is anyone thinking/concerned about the pending Chrome 80 update in Feb? The people over at Cornerstone told me that…
“Google is making changes to Chrome’s Window Close behavior that will impact how online courses communicate a user’s exit and completion status to our learning platform.”
I’ve installed Chrome Canary and tested my courses (published with v18.1.4) on SCORM Cloud. Everything seems to function just fine. I’ll test a slightly older publish with v17, but anticipate it will work as well.
Just wondering if this is one any one else’s radar, or if they have definitive information one way or the other.
BrianRThis post has received 1 vote up.January 12, 2020 at 11:40 am #436979
Brian RoemerMember6 pts@broeme
Quick follow-up. A course published with v17.1.3 worked just fine as well.
The test was with Chrome Canary on SCORM Cloud. It was a SCORM 1.2 course launched in a separate window with no interaction data.
BrianRThis post has received 1 vote up.January 15, 2020 at 6:41 pm #437251
sheryl cogginsModerator3 pts@scoggins3221
Chrome 80 will “Disallow synch XHR in page dismissal” link here
When the user clicks the close button on the internet browser window the course performs a final call to save progress, variables and completion data to the LMS. This is a call to the LMS and is a common action of e-learning software. Chrome version 80+ will no longer allow the LMS to save data using the current typical method. As a course administrator you may see that student progress, course variables, or completion status is lost when the student is using Chrome 80.
Technically, the SCORM course calls APIs in an LMS’s SCORM Player to save course data. The LMS SCORM Player is responsible for ensuring data is saved to the LMS, not the SCORM content / course. So IF the SCORM Player is using synchronous XHR requests (the Chrome 80 change) during page unload then the LMS needs to do something different. Most LMS providers have used this method.
For AICC the course is responsible for sending data to the server. If you use Lectora read the Resolution section below.
LMS data recording of content published for xAPI, AICC, and SCORM, as well as, content running in CourseMill.
Customers will encounter this issue only when students: 1) are using Chrome browser version 80+ and 2) they close the course with the browser window’s Close button (usually the x).
SCORM: LMS providers may need to modify their systems to ensure data is saved. SCORM courseware will not have to change or be republished.
AICC: Trivantis has a software update that will be deployed with the next releases of Lectora and Lectora Online. Contact support if you have an immediate need.
xAPI: Most xAPI statements are sent when actions happen, if you are using cmi5 it might require some changes. We encourage authors to create exit buttons within the course and direct students to use these course exit buttons.
CourseMill: We are working on a resolution which will be in the next release of CourseMill.
AICC: To utilize the upcoming changes in Lectora, for AICC only, all AICC titles will need to be republished using updated versions of Lectora and Lectora Onlne. As of January 14, 2020, the updates are still pending. Please monitor our website pages for support and releases for announcements of new releases. https://www.trivantis.com/service-pack-downloads/
SCORM: Inquire with your LMS provider if they have updated their LMSCommit() function to resolve the synchronous XHR request change in Chrome 80. If they have implemented a change, then you should not have any further issues. If they have not implemented any change, then please use the alternative below.
If you have an old LMS running SCORM or cannot republish your AICC content, you might want to register with Google for a temporary exception for your LMS. You can register here:
Users should be directed to 1) not close courses using the browser window close button or 2) use an alternative browser.
January 24, 2020 at 8:02 am #437677
- This reply was modified 1 month, 1 week ago by sheryl coggins.
Hi Sheryl, thanks for the information. Does this mean that progress won’t be saved if the course is closed (by the window ‘x’ button) on any page? for example, if a user is half way through a course and closes it, will their progress be lost due to this Chrome 80 update, or is this just applicable to the completion? I would assume it affects all progress.
Also, regarding the suggested workaround of directing users to not use the course window ‘x’ button; does closing the course from a button within the actual content have some other effect that does not cause the issue?January 27, 2020 at 11:28 am #437868
Joe WielochModerator53 pts@wheels
You are right it affects all progress, or variable changes.
Lectora only tells the LMS SCORM Player to commit changes if certain values change, such as AICC_Lesson_Status or AICC_Score otherwise we were relying on an exit action being called, or we call commit on a page unload. However, some LMSs like Scorm Cloud don’t wait for content to commit their changes, they have their own algorithm of saving which is likely on a timed interval. For SCORM the saving of course data is the responsibility of the LMS. If you want to ensure data is saved at certain points, and your LMS saves data when the course calls commit, you can use the trick specified in this post.
Our exit action processing does a commit which may cause the LMS to do a synchronous call saving the data, this would be happening on a user action in the course, not on page unload. The page would then be closed by scripting after the data was saved, so the Chrome 80 behavior should not come into play.
February 5, 2020 at 2:31 pm #438509
- This reply was modified 1 month ago by Joe Wieloch.
Andy LockwoodMember12 pts@alockwood6897
Is it possible that this has been happening already?
We’ve been trying to track down what we call a “progress tracking issue” where the user will go in, do some stuff in the course, close out, and the next time they come back, that progress has not been saved. This sounds very similar to what we’ve been experiencing, except we don’t have Chrome 80 and we’ve been dealing with this issue for over a year now.
It being attached to the user’s browser exit might explain how it is affecting some of our users but not others – but of course, how do you get it into their heads that they need to not use the browser exit button? We have it in text, in video, and remind them with almost every help call/email.February 5, 2020 at 3:10 pm #438511
@alockwood68, the most obvious thing to do would be to add an Action to each course that explicitly sets the AICC variable when the user satisfies the criteria, e. g. passes the assessment. The downside: lots of work.February 5, 2020 at 3:50 pm #438513
Andy LockwoodMember12 pts@alockwood6897
@carlfink, The AICC variable is there – the problem is that we’ve built a non-linear course that allows the user to move through different content paths.
The end scenario is gated – you can only access it after you’ve completed all the learning areas (in whatever order you choose). BUT some of the users are dealing with an issue where some (if not all) of their course progress is not being recorded, so when they get to the final assessment, they can’t access it because the course thinks they haven’t completed some of the content.
So, the AICC could actually complete the course if the users tripped it, but we need them to complete a bunch of hurdles first, rather than rush right to the final test.February 6, 2020 at 3:35 pm #438574
I’d have to see the actual course, but you could create custom variables that get set to “1” when the user completes a prerequisite, and can never be set back to “0”.
You must be logged in to reply to this topic.