The pipwerks wrapper (and SCORM) do not use xmlhttprequest. If the browser is throwing an error due to synchronous xmlhttprequest, then it's 100% on the LMS.
Asynchronous code is safer because it doesn't block the browser, and you can avoid making the browser feel broken. However, it requires use of callbacks, which complicates the cosebase, especially for people who are not comfortable working with callbacks. This was a big deal 10-15 years ago when callbacks were less common and built-in functions/libraries for handling callbacks (e.g. promises) were not available. Chances are, your LMS's SCORM system was written 10+ years ago, and uses synchronous xmlhttprequest when the page is unloaded. This is triggering the error in Chrome.
From the Chrome blog: "Chrome now disallows synchronous calls to
XMLHTTPRequest() during page
dismissal when the page is being navigated away from or is closed by the user.
This applies to
If your LMS vendor wrote their own SCORM codebase, I can pretty much guarantee you that they will not want to update the SCORM code to avoid this Chrome 80 issue. It will cost them money, and it is very likely they don't even have a developer fluent in SCORM on staff anymore because the code was written years ago and has not been updated in years.
LMSs that use a vendor-provided solution such as Rustici Software's system will likely receive updates because the 3rd-party vendor maintains the SCORM codebase.
Regardless, it is outside the scope of the course and needs to be handled on the LMS end. There is nothing you can do about it except avoiding invoking beforeunload and unload, which goes against SCORM best practices.
You can give your students a button to click at the end of the course which will handle your end-of-course scripts and trigger Commit() before the page unloads, but it doesn't address what happens if the student leaves mid-course. It's up to you to re-examine your use of beforeunload and unload to ensure that you're committing your student's data regularly. In my courses, I have a script that detects whether the page's activity is complete, and if yes, updates the completion status and bookmark. In my courses, beforeunload and unload trigger one last Commit() as a 'just in case' but I am confident the data has already been committed. If you wait for the unload or beforeunload events to trigger before executing Commit(), you're asking for trouble.
If you're confident your data has been saved correctly prior to beforeunload and unload being called, you can choose to remove your beforeunload and unload handlers, or simply ignore any errors they generate.
The pipwerks wrapper does not invoke unload or beforeunload. It was designed to allow you to invoke Commit() -- aka scorm.save() -- in your course wherever you see fit.