3.5.7, 3.6.5, 3.7.1, 3.8
MOODLE_35_STABLE, MOODLE_36_STABLE, MOODLE_37_STABLE, MOODLE_38_STABLE
MOODLE_35_STABLE, MOODLE_36_STABLE, MOODLE_37_STABLE
I'm trying to write a step to select a repeated field where each repeat is in a different fieldset.
I first considered adding the name of the fieldset to the langstring, but this seems wrong as I suspect that the name of the fieldset will also be read out by a screenreader so context is maintained (not yet verified).
So I've been looking to amend the find_field step to support the standard > notation, i.e.
I then explode on the ">", use this to find the "Ratings" fieldset, and then look for the "Grade to pass" within that fieldset as you would expect.
That is relatively easy and should work, however the way that the optional container $node is specified takes the xpath for the target ("Grade to pass" "field") and explodes it on the pipe character ("|") which is an xpath UNION operator.
It then prefixes each component with the xpath of the container.
All good in theory, except that the pipe operator is a perfectly valid operator in the middle of an xpath too.
When prefixed with:
Note the section:
To clarify further...
That final /self::select] does not have a matching [ because in the original xpath it was paired before the UNION operator.
So it's an invalid XPath. It's valid to specify a UNION in the middle of a pair of  brackets in this way, butthe xpath prefix we were performing was not intelligent enough to know how to handle it.
After spending several hours trying to find a solution to my behat test failures, I have found the solution... just call findAll on the container $node.
The Mink driver already makes use of Behat\Mink\Selector\Xpath\Manipulator to prepend the node to the container, and that manipulator is aware of the union operator and how to do it properly.
This feature was introduced in Mink 1.7.1 in 2011 but we started with Mink 1.4 which did not contain this feature.
The upstream implementation is almost identical to the one I am removing... the key difference between the two is that the upstream implementation uses a preg_match with lookahead to ensure that it only picks up pipes which are not in brackets (which was the bug I was experiencing).