Details
-
Bug
-
Resolution: Fixed
-
Blocker
-
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
-
MDL-66378-master -
- Update the CI testrunner to stop pinning to the -mercury release
- Ensure that it has been deployed
- Kick off behat runs
Description
On my system (Windows 10), Behat has stopped working since upgrading to Chrome/ChromeDriver 76 (Selenium 3.141.59).
In Chrome 76 they moved to using W3C by default.
It is possible to tell it not to but that requires a modification to the upstream webdriver project and they’ve gone largely silent.
I’m actively working on moving us to the Facebook webdriver project which I’m also actively working on getting to support W3C browsers natively. Whenthat happens, hopefully in the next few weeks, we will be able to run behatin Safari, Edge, Firefox Quantum, and Chrome 76+.
In the meantime I’m thinking we should patch the instaclick webdriver wecurrently use to make it stop using W3C in chrome 76.
In our CI infra we’ve hard coded use of the Selenium 3.141.59-mercury Docker image which is chrome 75.
Original description from Sam below
I tracked down the problem and was able to 'fix' it by inserting the following 3 lines at the start of the webDriverElement function in Behat, vendor/instaclick/php-webdriver/lib/WebDriver/Container.php:
protected function webDriverElement($value)
|
{
|
if (!array_key_exists('ELEMENT', $value)) {
|
$value['ELEMENT'] = $value['element-6066-11e4-a52e-4f735466cecf'];
|
}
|
The reason this fix works is that a return value containing elements from Selenium WebDriver, as defined here https://w3c.github.io/webdriver/#elements , has the array key 'element-6066-11e4-a52e-4f735466cecf' but the code here is expecting the array ky 'ELEMENT'.
I confirmed this in the code by basically adding in print lines all over, so that I could output the result from Selenium, like this:
Array
|
(
|
[value] => Array
|
(
|
[0] => Array
|
(
|
[element-6066-11e4-a52e-4f735466cecf] => a8a95466-aa17-4ca2-a47c-be0f11eae163
|
)
|
)
|
[info] => Array
|
(
|
[url] => http://127.0.0.1:4444/wd/hub/session/230f9969f65d4135b4eba3a87a1335a3/elements
|
[content_type] => application/json;charset=utf-8
|
[http_code] => 200
|
[header_size] => 284
|
[request_size] => 305
|
[filetime] => -1
|
[ssl_verify_result] => 0
|
[redirect_count] => 0
|
[total_time] => 0.056372
|
[namelookup_time] => 7.5E-5
|
[connect_time] => 0.000774
|
[pretransfer_time] => 0.00091
|
[size_upload] => 101
|
[size_download] => 224
|
[speed_download] => 4000
|
[speed_upload] => 1803
|
[download_content_length] => 224
|
[upload_content_length] => 101
|
[starttransfer_time] => 0.056352
|
[redirect_time] => 0
|
[redirect_url] =>
|
[primary_ip] => 127.0.0.1
|
[certinfo] => Array
|
(
|
)
|
[primary_port] => 4444
|
[local_ip] => 127.0.0.1
|
[local_port] => 52309
|
[http_version] => 2
|
[protocol] => 1
|
[ssl_verifyresult] => 0
|
[scheme] => HTTP
|
[appconnect_time_us] => 0
|
[connect_time_us] => 774
|
[namelookup_time_us] => 75
|
[pretransfer_time_us] => 910
|
[redirect_time_us] => 0
|
[starttransfer_time_us] => 56352
|
[total_time_us] => 56372
|
[request_method] => POST
|
)
|
[sessionId] =>
|
[sessionUrl] => http://127.0.0.1:4444/wd/hub/session/230f9969f65d4135b4eba3a87a1335a3/elements
|
)
|
I had also been experimenting by directly posting things to the WebDriver endpoint without using Moodle/Behat code, with similar results.
Anyway, obviously if this is a problem it would be a problem upstream, but I am not at all clear it is an actual problem vs. me screwing up, because I don't see how the code would have worked before.
I'll attach the change as a patch.
