The simple pattern matches were conflicting in some situations. To make
this backwards compatable we need to convert it to a Regex pattern match
instead, and provide the quoted and unquoted variants.
There were two issues here:
* I am on the [categoryname] category page page (duplicated page)
* the wrong URL was being used
Since an incorrect URL was used I felt it safe to rename the step from
'category page page' to 'category page'.
This commit makes the following improvements to core page resolverss:
* allows for mixed case naming (course, Course, etc.)
* allows fields other than the idnumber to be specified:
** course: idnumber, shortname, fullname
** course category: idnumber, name
Whilst some of these fields are not unique, they will typically be
unique in most test scenarios. Where they are not then the idnumber
should be used in preference.
Move the close button out of the element that is set as the
aria-labelledby for the dialog.
Also used h5 for the dialog titles so they are consistent with
AMD modals.
The initial focused element should be the first operator button.
This commit also fixes the accessibility issues that previously were
wrongly fixed by a redundant click on the first tab using javascript.
Clicking in a day in the three month block replaces the div with id starting
with calendar- so we can do so repeatedly and successfully and test that it does (with behat).
The activity generator currently requires an idnumber when creating
activities, but this is not a requirement when creating the same
activity through the UI. The requirement comes because we want to
provide a way to refer to activities in subsequent steps.
This commit modifies the behaviour such that the generator uses the name
of the activity as the default idnumber.
This has two main benefits:
1. it simplfies generation of activities; and
2. it makes the language used when writing behat tests much more natural.
With this change, steps will refer to the activity by its idnumber/title
in all cases, rather than sometimes by an idnumber which bears no
relevance to the title.
The `page_type_list` method for the message component was deprecated
in 5b0769db as part of MDL-54744. However it is still required when
trying to configure blocks on any messaging pages.
After a major upgrade was done in h5p.com, some random errors appeared
in the "H5P options are ignored for H5P URLs" scenario.
They have been fixed replacing the URL for different (which should
load quicker). As we're checking external content, no other improvement
can be done on the Moodle site.
Take account of parent languages when requesting given library
translation. For example if we are currently using "de_kids" as the
current language, we need to recurse each language pack looking for
a matching H5P translation ("de_kids" -> "de_du" -> "de").
A similar approach was followed @ MDL-67935, although the
case doesn't seem to be the same.
In any case, it's curious that all local execution are
100% passing and only CIs fail so often. Just guessing if,
maybe, there is some Chrome version factor around (we
are running older, sticky, versions @ CIs.
