Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
3.0.3, 3.0.4, 3.0.5, 3.1, 3.1.1
-
MOODLE_30_STABLE, MOODLE_31_STABLE
-
MOODLE_30_STABLE, MOODLE_31_STABLE
-
MDL-55312_load_timeout_for_amd_modules_master -
Description
In some cases, after purging caches, a javascript error will occur on the course page and can be seen in the js console:
Load timeout for modules: core/first
This happens typically if the web server is slow, or if you are using a device with low bandwidth, or if there are lot of resource / activity modules installed on the moodle, or you have a lot of embedded content (see steps to replicate). There maybe other circumstances that cause the error too.
Having inspected the network tab on the course page after purging caches, there are a large number of requests inbetween require.js and first.js (at least 19).
In some cases (slow web server, or lots of module icons), the requests inbetween require.js and first.js block first.js from loading for more than 7 seconds (this is the default timeout require.js uses for waiting for modules to load).
This results in the error message "Load timeout for modules: core/first"
Steps to replicate:
Download and enable the oembed filter
Make sure it is configured so that 'lazy loading' is switched off.
Restore the attached course
Purge caches
Open network tab
Go to the restored course (you should see you tube videos loading) and wait for network tab to finish loading everything
Sort the network tab by time started
Observe that require.js is more than 7 seconds away from first.js due to blocking (max concurrent requests).
Suggestions for fix:
lib/requirejs/moodle-config.js should have a waitSeconds entry as follows
var require = {
|
baseUrl : '[BASEURL]',
|
// We only support AMD modules with an explicit define() statement.
|
enforceDefine: true,
|
skipDataMain: true,
|
waitSeconds : 0,
|
This makes require.js wait eternally for modules to load which is fine in production. In development mode you might want it set to a lower value.
I've tested this in moodle 3.0 and 3.1
I've assigned it a priority of 'critical' because it breaks pretty much all javascript on the page when this bug happens.