Calling browser.timeouts() for Safari tests in a hook errors and results in rest of hook not executing

[christian-bromann]

From @jochakovsky on October 31, 2018 1:0

Environment (please complete the following information):

• WebdriverIO version: 4.14.0
• Mode: WDIO Testrunner
• If WDIO Testrunner, running sync/async: sync
• Node.js version: 8.11.2
• NPM version: 6.4.1
• Browser name and version: 12.0.1 (13606.2.104.1.2)
• Platform name and version: macOS 10.13.6
• Additional wdio packages used (if applicable):

Config of WebdriverIO https://github.com/jochakovsky/webdriverio-browser-timeouts-bug

Describe the bug Calling browser.timeouts() for Safari tests in a hook throws the following error:

Error: Remote end send an unknown status code.
    at timeouts("implicit", 15000) - index.js:263:37
    at init() - runner.js:235:55

For me, I put the call to browser.timeouts() in the before hook, and this error prevented the rest of the hook from executing. In my real project, there are some critical commands run afterwards in the same hook. Since those were skipped, my tests would fail for very hard-to-debug reasons.

No issues setting timeouts in Chrome or Firefox.

To Reproduce Steps to reproduce the behavior:

• Clone https://github.com/jochakovsky/webdriverio-browser-timeouts-bug
• npm install
• in one shell, $ java -jar -Dwebdriver.gecko.driver=./geckodriver selenium-server-standalone-3.14.0.jar
• in another shell, $ ./node_modules/.bin/wdio wdio.conf.js

Expected behavior Any of the following:

• Correctly setting the timeout
• A clear error message that it is not possible to set the timeout in this browser referencing the line number of the browser.timeouts() call, and the WDIO test runner exits with a failure code
• A clear error message that it is not possible to set the timeout in this browser referencing the line number of the browser.timeouts() call, and the WDIO test runner continues executing the hook

Copied from original issue: webdriverio/webdriverio#3029

[christian-bromann]

@jochakovsky this could be a bug with Safaridriver or the way how WebdriverIO v4 supports Safaridriver. Feel free to propose a fix for this.