Most types of form field will now include aria-required="true" if the
field is marked as required. This causes assistive technology to inform
users that the field is required.
Before this change, in some cases (e.g. screen reader users tabbing
through fields) users were not informed that a field is required.
Since 4be39296 the root HTML element contains the iso6391 language
code of the current language pack. However various JS modules need
access to the original Moodle language pack code, so expose that
in the `M.cfg` structure.
* Create SRLogger that extends from the default Logger class. This
logger outputs the feedback to a sr-only ARIA live region to allow
screen readers to announce the feedback from mutations.
* Update the course editor to use the SRLogger.
* Create a mechanism for logging mutation feedbacks.
* The mutation feedbacks are displayed as a toast by default.
* Apply this logging mechanism on the course homepage to provide
feedback for the results of actions performed on course modules and
course sections.
* When reloading a section, we also forced the reloading of
course modules, resulting in doing the same work twice (once for
the section reload and once for the course module reload)
* Debounce the reloading process so prevent unwanted duplicate
reloads
Previously, the type of share (course/activity) was being injected into
the string, but not from a translation, so did not fully translate. The
MoodleNet type (resource) was working, but has also been replaced here
to avoid inserting one string into another (this was also unnecessary
while resource is the only possible option). This also meant the latter
string could be deprecated.
The Binary datafilter was returning a single value where all parts of
the API expect an array of values. This was working in most places by
fluke as this value was a single-character string, so doing $value[0]
returned the value. However, it was not working when deciding which
option to mark as selected when re-displaying the filter.
This change makes the filter return an array containing a single integer
value to match the rest of the API, then internally selects that single
value for comparison when deciding if an option should be selected.
New event in core/sticky-footer that is fired when the sticky footer has
been enabled or disabled. Leveraging this event, modules can create
event listeners and execute actions once the sticky footer has been
toggled.
Implements a base js class that each individual bulk action
implementation needs to extend. This class contains all common event
listeners, methods (including abstract) that each implementation need
to use. Also, it introduces a default mustache template for the bulk
action trigger elements.
Introduces a base js class that bulk actions area implementations need
to extend. This class contains all common selectors, event listeners,
methods (including abstract) that each implementation would use.
Also, introduces a common template for the bulk actions area.
If the footer property is a Templates.render() promise, and the modal is
set to show immediately (show=true), the show() logic - which contains
the footer show/hide logic - can run before the footer content is set
(i.e. before the promise chain is complete). In such cases, the footer
will be marked as hidden and must be made visible again.
This change includes some additional simplifications to support this
change, including conversion from done/fail to then/catch, and some
simplification of Promise usage.
There were a number of cases of nested Modal usage which have been
removed.
This commits adds a new static `create()` method to replace the existing
ModalFactory.create approach.
This allows the creation of a modal to now be simplified to:
```js
import SomeModalClass from 'mymodule/wherever';
// ...
const modal = await SomeModalClass.create();
```
Prior to this change the modal was instantiated via the ModalFactory,
but the Type of modal was typically pulled from the ModalClass itself
via the registry. Essentially it used to require three modules to
instantiate a single Modal, and now it takes just one.
This change moves configuration of the modal from the ModalFactory to
a new `configure` function on the Modal class which does exactly the
same thing. This means that the API is fully encapsulated within the
Modal, and an individual Modal can specify its own configuration more
easily.
This change will make it much easier to instantiate new modals,
significantly reducing boilerplate in many instances.
This change allows modals to extend the `configure()` method to provide
their own defaults, or to override standard ones.
```js
class MyModal extends Modal {
static TYPE = 'my_module/mymodal';
static TEMPLATE = 'my_module/mymodal';
configure(params = {}) {
// Override the default value for large.
params.large = true;
super.configure(params);
// Handle our own properties here.
const {
makeSound = true,
} = params;
this.setSoundEmitter(makeSound);
}
```
Prior to this change, it was common to see this happen in the _calling_
code, rather than the modal itself.
This addresses a random failure with the combobox search results where
the debounce causes the results to be shown, and then the same search
result is returned again, re-rendered, and replaced after Behat has
moved on.
Laurent David