From Selenium 4.8.0, support for non-w3c browser control has ended.
We only use W3C browser control these days, and this was missed as part
of the move to W3C. All browser options must be vendor-prefixed.
PHP before version 8.1 automatically converted to int if the function
parameter (or array key) is expected to be int. PHP 8.1 shows notice in
this case
This will find all data generators that can be used in behat via the
'the following "something" exist:' step, and display them in a select
list on the step definitions page.
When a generator is selected, it will fetch the required fields for that
generator and display them on the page.
Default value of the $flag argument changed in PHP 8.1 from ENT_COMPAT to ENT_QUOTES | ENT_SUBSTITUTE
To ensure consistent behavior across different PHP version the second parameter is now required for the functions:
htmlspecialchars(), htmlentities(), htmlspecialchars_decode(), html_entity_decode() and get_html_translation_table()
These steps have accepted a NodeElement instance as an argument for some
time, but were trying to cast it to string when formulating exception
messages, making it harder to debug and, in the case of the 'should see'
step, not work at all.
This patch introduces a new function to produce a consistent naming for
them.
This commit adds new steps related to action menus to support:
* Choosing an item in a named action menu
* Choosing an item in a named action menu within a container
* Confirming that an action menu item does or does not exist in a named
action menu
* Confirming that an action menu item does or does not exist in a named
action menu within a container
The existing action menu steps were insufficient as they assume that
there is only one action menu within he container, which is not
necessarily the case.
The existing action menu steps are not non-JS friendly and will error if
JS is disabled, without providing any fallback when one is easily
available.
Unfortunately these steps cannot be used to replace the existing steps
without manual intervention.
Prior to this commit, the behat_form_editor integration was hard-coded
to use Atto.
This change allows other editors to be used to set editor values, and
breaks that hard bond. Following this change, any editor is able to
define a behat_editor_[name].php file defining a function which meets
the following signature:
set_editor_value(string $editorid, string $value): void
Each editor is responsible for checking whether its own API is available
and calling any relevant functions to force the editor to set the
content.
Please note: Behat is unable to determine the current editor in use on
the page automatically.
This change, which should be easy to mimic for other editors.
This will ensure that the correct editor is used for tests relating to
that editor, or its subplugins.
This commit introduces a new partial selector for select_menu fields,
and teaching the field manager how to recognise these, then introducing
a new field type which can handle setting values for this field.
It has been detected, thanks to php80 specially, that there are
various places in core where support for localised floats is
missing. Before php80, some locale-dependent conversions were
performed by PHP, allowing things to work. But with php80 all
those comparisons are now locale-independent. See:
https://wiki.php.net/rfc/locale_independent_float_to_string
That implies that we now need to, always, unformat floats to
be internally the correct (decimal point as separator) in
order to compare it.
While this was visited in the php80 epic (MDL-70745), nothing
was found, all automated tests were passing ok. Problem is that
we run behat tests with en-AU laguage that has the decimal point
separator.
So, in this issue we are fixing all the problems detected by
running those Behat tests using localised (comma) decimal
separator.
Note that there may be other places still causing problems, but
it's really hard to find them programmatically, so we'll have to
wait for real use reports / issues and go fixing them while they
happen.
Back to this commit, this is the list of changes performed (note that
in the next commit, we'll be adding scenarios explicitly using
a localised decimal separator to ensure that they work ok).
A. Changes to various grade forms to ensure that, on their validation
floats are unformatted properly. Also, changed the corresponding
form element from current text/PARAM_RAW to proper float ones that
take care of the conversion in a number of places (but when disabled,
that's the reason we still have to unformat in validation.
This includes the following forms:
- edit_category_form
- edit_item_form
(this is the original problem reported that cause all the research
to be performed against full behat runs)
B. Changes to edit_letter_form, so it uses a proper PARAM_LOCALISEDFLOAT
(note this is the type of change that surely should be used for all
the rest of /grade/edit/tree form, including those in the previous
point).
C. Changes to the grade_item behat generator, so it's able to work with
localised floats, un-formatting them when needed.
At lib/behat/classes/behat_core_generator.php
D. Fix problem passing localised floats to scales, not displaying
properly. At grade/report/singleview/classes/local/ui/finalgrade.php
E. Change the behat text matcher in order to allow comparison of
localised floats when they are the current ones. Before this change
the matches was using soft/lazy comparison, so '50' and '50.0000'
match. Now, when the comma (for example) is used (and only then),
'50' and '50,000' will also match. This comparison is in use in a
bunch of tests and makes sense to make it localisation-aware.
At grade/report/singleview/classes/local/ui/finalgrade.php
F. Fix a couple of number_format() uses in lesson, because they are
not localised-aware. Switched to format_float(). At mod/lesson/locallib.php
G. Change the quiz_contains_the_following_questions() step to accept
localised maxmark expectations. At mod/quiz/tests/behat/behat_mod_quiz.php
H. Change the quiz generator so it accepts localised gradepass.
At mod/quiz/tests/generator/lib.php
I. Change the edit question form to show proper localised penalties,
previously it was always showing point-decimal ones. Of course,
leaving the values of the select element unmodified (internal floats).
Related, also change a couple of tests to, instead of try to match the
value (always internal floats), match the description (now localised),
so we can test them with different separators. At:
- question/type/ddimageortext/tests/behat/backup_and_restore.feature
- question/type/ddmarker/tests/behat/backup_and_restore.feature
- question/type/edit_question_form.php
Andrew Nicols