Note: Internet Explorer
Absorb will be deprecating support for Internet Explorer (IE) 11 in 2022. Please see important dates below:
- Absorb will discontinue fixing IE 11 specific issues on August 31, 2022
- Absorb will fully drop support for IE 11 on November 30, 2022
These dates align with the Microsoft changes to IE 11 on June 15, 2022. Please visit The future of Internet Explorer on Windows 10 is in Microsoft Edge for further details.
We have investigated reports of courses exhibiting unexpected behaviour, most of which are still limited to the latest version of Chrome but with several reports from other browsers including Safari, Firefox, and Edge. Here is what we have discovered so far:
- Our first fix for this issue was released on May 31st, shortly after Chrome 83 started broadly rolling out. We believe this fix resolved the underlying issue that Chrome introduced with their v83 release on May 19th. However, we have identified several edge cases that our fix either does not resolve, or that it may be exacerbating. To address these edge cases, we are actively working on the following changes:
Reducing the scope of our original fix to only affect browsers that have implemented this change
- This should resolve the issues in Firefox and older versions of Chrome or Edge. The latest version of Chrome, Safari, and Edge all need our original fix though, so they will not benefit from this change. This is also a short-term solution as all browsers are likely to adopt this change, and most users will eventually wind up on the newer versions of the already affected browsers.
Reducing the size of SCORM calls from courses back to the LMS
- Our original fix relies on a different kind of communication between the course and the LMS compared to what used to be available, and unfortunately, this new communication has a maximum size allowed for SCORM calls. The size of these calls can vary widely between different courses as well as different attempts, but we have identified some records with 3 or 4x more data than is now allowed. We are looking into methods to reduce the size of these calls so that they can fit under the new maximum.
Resolving concurrent SCORM calls to not block each other
- Prior to the change in Chrome, SCORM calls would be sent in sequence, i.e. one after the other. However, to accommodate the browser change, we had to modify our SCORM calls to operate in parallel, i.e. multiples of the same call could be sent at the same time. We have discovered that some courses, either by design or by user behaviour, can send many SCORM calls in a very small amount of time which wind up blocking each other as they try to record their data to the LMS. We are working to mitigate this in several different ways.
- Reducing the scope of our original fix to only affect browsers that have implemented this change
Additional Background Information
- Chrome originally announced its intent to deprecate this functionality in late 2019 with chrome v77. You can read more about their reasons here (warning, very technical) but the gist is that allowing websites to run things when a tab or window is closed can be abused in ways that we have probably all seen on the internet, e.g. spam windows that open more windows, non-stop dialog messages, etc.) In that context it is understandable that they no longer wanted to support this, but unfortunately for the e-learning world, SCORM is a very old standard and many implementations of it tend to have a reliance on obscure features like this. When we first heard about this change, we reviewed our SCORM implementation and determined that we should be unaffected by the change. Chrome actually wound up delaying the change to v80 (release notes here, it’s the second item) which was released in February and as expected we did not see any significant reports of issues from clients.
- Fast forward to May, when we started seeing more reports than normal about courses not reporting correctly. It is hard to pinpoint exactly when this started ramping up, but we were able to narrow down the issue to Chrome v83. Specifically, it appeared that courses that were working fine up until v83 was released were suddenly no longer reporting correctly. Given that the change that should have affected this was apparently released in v80 3 months earlier, it is still unclear to us why the issue was only appearing now. However, we identified a fix and implemented it on the 31st, which appeared to resolve all currently reported cases. Since then though, v83 has been gradually rolling out too many more users (it is now about 80% of all Chrome users) and we have been receiving additional reports of courses failing even with our fix in place. Due to the complexities of the interactions between browser, course, and LMS (of which we can only control one) it has taken us quite a bit of time to pinpoint the edge cases that are failing. The three that we have identified above may not be the last, but they should resolve most of the cases that have been reported to us in the past 2 weeks.
As a long-term comment on this issue, it is unlikely that we will be able to resolve this issue 100% on our own. By far the best solution to this problem is for SCORM courses not to rely on the closing of the browser window or modal as the only, or the final, communication of learner progress to the LMS.
Many course authoring tools have issued updates that implement fixes on the course end (e.g. Articulate Storyline 360), but it will require you to re-author your course from an updated version of the tool. If you have access to the original course files and you are currently experiencing an issue with your course reporting properly, we would strongly recommend that you take this step as even our proposed fixes above may not completely resolve your issue.
We appreciate that this issue has created significant disruption for your operations and is likely generating a substantial support burden for you with your end-users. We are working as quickly as possible to implement fixes in a safe manner and will provide ongoing updates on our progress.