The legacy M.core.event.FORM_SUBMIT_AJAX ecent has been replaced with a
new core_form/events::formSubmittedByJavascript native DOM event.
The new event can be listened to at any point in the DOM using the
following syntax:
```
import {eventTypes} from 'core_form/events';
document.addEventListener(eventTypes.formSubmittedByJavascript, handler);
```
A backward-compatabibility layer is included to ensure that any
legacy YUI event triggered on a form is still respected and the new
native event is also fired.
A similar handler is also included to ensure that any legacy YUI event
listener is still called with the same arguments.
These legacy bridges will be removed after Moodle 4.3.
Issue 1: While essay question's uploading progress, we need to disable submit
buttons to prevent submit form event.
Issue 2: Enable buttons after pressing cancel button on the popup
confirming overwrite file existed.
It seems that the new phpcs3 checker is now controlling those
line comments that previously were ignored.
This commit just looks for all the cases and bulk-add
them when needed. The bash script (mac) used to add all them is:
while read -r line; do
arr=(${line//:/ })
if [[ -n ${arr[0]} ]] && [[ -n ${arr[1]} ]]; then
echo " file ${arr[0]}, line ${arr[1]}"
sed -i "${arr[1]}s/\$/\./" ${arr[0]}
fi
done < <(find . -name version.php | xargs ag --nomultiline '>(version|requires) *=.*//.*[^;\.]$')
Without this, people can craft URLs that other users might use not realising
what they do - and as a XSS vulnerability, it could do any number of things the
clicking-user has access to do on the site.
Change-Id: I82adc71e8706d8929011b4b24523d5b62b8ccea1
In order to allow for correct seb:// or sebs:// calls without browser
warnings of insecure links, it is not possible to send a get request
with an attached cmid parameter to the unknown seb:// or sebs://
URL via a form button.
We've got to use a <a href> link outside a form to circumvent
browsers warning of an insecure link and call Safe Exam Browser
correctly.
Other tests check behaviour of individual conditions, this tests that
when multiple core and custom conditions are required, each will be
updated as required and not cache until all are completed.
