Instead of doing an exact checking of the page title in
\behat_hooks::before_step(), do a more lenient check by checking that
the page title contains the acceptance test's site name.
In the Moodle additions for the Bootstrap Dropdown we update the focus
after a 50ms delay. This is presumably because the targetted focus point
may not have shown yet and may be opened in a separate thread, though
sadly the original reasoning is not documented, and is not mentioned in
the original issues.
As a result of this delay, it was possible for the user to start to
interact and then have focus stolen from them. In reality this does not
happen often - 50ms is simply too short a time for a human to do so, but
it is plenty of time for Behat to do so and we have seen some random
fails as other parts of the UI become faster. When this happens,
keyboard focus tests are broken by this 50ms behaviour.
The fix here updates the shift focus function when closing the menu to
check whether the focus has changed from the previous location already
before setting the focus.
* Use the page title separator constant when displaying the page title
during upgrade and installation.
* No need to display the site name during install when because it hasn't
been set at this point.
* Page titles should display the most unique information first. For
admin pages it would be useful to display the information that
is unique to the page first before the broader categories that the
page belongs to.
* Also use the new page title separator constant.
MDL-78806 core: Remove redundant site name on page titles
* With the site name now being appended to the page titles, there
is no need to manually append the page titles.
The core/utility confirmation modal can be used in this case to confirm
backpack actions. It is not necessary to have a custom module for this
purpose.
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 commit includes some simplifications to the way in which some of
the modals are launched and allows us to remove several modules entirely
as they are no longer required following the simplification of the Modal
instantiation.
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.
