Status: Development in progress
Affects Version/s: 3.5.9, 3.7.2, 3.8
Fix Version/s: None
- Chrome 80 or greater (dev version in the moment of writing this test)
Scenario 1 (scorm):
- When execute behat test: mod/scorm/tests/behat/save_progress_on_inload.feature
- Then test should pass
Affected Branches:MOODLE_35_STABLE, MOODLE_37_STABLE, MOODLE_38_STABLE
Pull from Repository:
Pull 3.5 Branch:MDL-67175-35
Pull 3.5 Diff URL:
Pull 3.7 Branch:MDL-67175-37
Pull 3.7 Diff URL:
Pull 3.8 Branch:MDL-67175-38
Pull 3.8 Diff URL:
Pull Master Branch:MDL-67175-master
Pull Master Diff URL:
Sprint:Moodle 3.9 - Moppies Kanban
Hi guys and girls,
I couldn't find a ticket for this one, and while it has popped up in your forums I don't know that anyone has seen it.
Quick grep of code doesn't reveal any introduction of the SameSite property.
There are two changes coming in Chrome 80 that you may want to prep for (we certainly are)
It will no longer be possible to make synchronous XHR requests during page dismissal.
No more synchronous XHR requests on beforeunload, unload, pagehide, and visibilitychange.
The SCORM API makes use of synchronous XHR requests, and it is somewhat common for packages to attempt to save use progress when they leave the SCORM activity, in fact the example 2004 packages do this.
Arguably it could be the SCORM authoring tools responsibility to ensure that it does not attempt to save progress on exit events. However the Moodle SCORM JS API is pretty basic and its an easy fix within Moodle.
For those affected by the problem there are four workarounds, none of which are particularly good.
- Every user of Chrome 78 or greater changes their browser settings to disable the "Forbid synchronous XHR requests in page dismissal" - navigate to chrome://flags/#allow-sync-xhr-in-page-dismissal - This may be a short term fix, I'm unclear on whether it will be removed with the AllowSyncXHRInPageDismissal policy flag noted below; it may well be.
- Organisations using Enterprise policy controls can enable the AllowSyncXHRInPageDismissal flag. This is a short term fix as the flag is expected to be removed in Chrome 82 https://cloud.google.com/docs/chrome-enterprise/policies/?policy=AllowSyncXHRInPageDismissal
- Register for a temporary opt-out, this is available on a site by site basis until October 2020. After that date the opt-out will not longer work. Every site has to register to get a token which must then be added to either the headers or page meta data. Instructions https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md.
- They instruct their users not to just navigate away from the SCORM package as they may loose some of their progress. Not a solution, just a mitigation.
There are several articles out there that are interesting reading in relation to this change:
- Bugs: Issue 827324: Disallow sync xhr in beforeunload
- Chrome platform status: Disallow sync XHR in page dismissal
- scorm.com Blocked SCORM Exit Postbacks with Google Chrome 78 and Above
- Moodle forums Chrome change affecting remotely hosted SCORM/AICC?
This is a twofer, you'll want to be aware of both changes.
The first is that the SameSite cookie property will begin to default to Lax.
This by itself isn't terrible, we can expect Lax to cause a little havoc in the way people use the site, but it is explainable.
There is a new value that was recently added to the list of accepted values, "None" which will return behavior to where it is presently.
Beware with this one there are a few gotcha's out there.
There is a bug in Safari (that appears to be bound to both the browser and the OS) wherein Lax will be treated as Strict.
IE has some quirks when handling it also.
After a lot of testing our approach was to detect Chrome 77 and start setting SameSite there. It's a stop gap solution, but works well given the inconsistent state of the property across browsers.
Chrome was originally going to make this change in 78, but pulled out and shifted it back literally a week before release.
In the future session management really could stand to be improved to more specifically control session start and cookie management - that would enable some really cool things to be done.
The second ties into this.
When SameSite is set to None Chrome is going start requiring secure cookies only.
If set to None then sites will need to be running https.
The mechanics are all in place already for this of course, and its been a recommendation for years, but flagging it up as we considered it relevant.