fix: Deal with new W3C spec Error response

[nextlevelbeard]

Proposed changes

Fixes #10843
Deal with new Chrome error responses to find element request.
Sometimes Chrome response is an error object like

{
    "error": "no such element",
    "message": "no such element: No node with given id found\n  (Session info: headless chrome=116.0.5845.50)",
    "stacktrace": "#0 0x55ddf07ae623 <unknown>\n#1 0x55ddf04d0f67 <unknown>\n#2 0x55ddf04b8527 <unknown>\n#3 0x55ddf04b6a94 <unknown>\n#4 0x55ddf04b700f <unknown>\n#5 0x55ddf04b6f64 <unknown>\n#6 0x55ddf04ddf16 <unknown>\n#7 0x55ddf04d5a34 <unknown>\n#8 0x55ddf04d4643 <unknown>\n#9 0x55ddf04d6d40 <unknown>\n#10 0x55ddf04d6dfc <unknown>\n#11 0x55ddf0514de8 <unknown>\n#12 0x55ddf05151b1 <unknown>\n#13 0x55ddf050b1a3 <unknown>\n#14 0x55ddf0535f3d <unknown>\n#15 0x55ddf050acf6 <unknown>\n#16 0x55ddf05360de <unknown>\n#17 0x55ddf054e249 <unknown>\n#18 0x55ddf0535ce3 <unknown>\n#19 0x55ddf05097bb <unknown>\n#20 0x55ddf050a55e <unknown>\n#21 0x55ddf076f648 <unknown>\n#22 0x55ddf0773547 <unknown>\n#23 0x55ddf077ddbc <unknown>\n#24 0x55ddf0774176 <unknown>\n#25 0x55ddf074251f <unknown>\n#26 0x55ddf0798458 <unknown>\n#27 0x55ddf0798628 <unknown>\n#28 0x55ddf07a74f3 <unknown>\n#29 0x7f60e12a0044 <unknown>\n"
}

instead of an array of elements that we have expected so far.

This change warps the element response in an array but then flats it till depth 1, meaning it maintains previous logic for an element response array but also wraps this new error object in an array. It will then be handled normally as other errors are, instead of crashing the test-runner with

elemResponse.map is not a function

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Checklist

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• I have added proper type definitions for new commands (if appropriate)

Further comments

Reviewers: @webdriverio/project-committers

[christian-bromann]

Can we have a test for this to avoid future regressions?

[nextlevelbeard]

@christian-bromann There is an issue in linux only, you aware of what might be the cause?

/home/runner/work/webdriverio/webdriverio/packages/wdio-reporter/cjs/utils.js:7
const supports_color_1 = __importDefault(require("supports-color"));
                                         ^

Error [ERR_REQUIRE_ESM]: require() of ES Module /home/runner/work/webdriverio/webdriverio/packages/wdio-reporter/node_modules/supports-color/index.js from /home/runner/work/webdriverio/webdriverio/packages/wdio-reporter/cjs/utils.js not supported.
Instead change the require of index.js in /home/runner/work/webdriverio/webdriverio/packages/wdio-reporter/cjs/utils.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/home/runner/work/webdriverio/webdriverio/packages/wdio-reporter/cjs/utils.js:7:42)
    at Object.<anonymous> (/home/runner/work/webdriverio/webdriverio/packages/wdio-reporter/cjs/index.js:9:20)
    at Object.<anonymous> (/home/runner/work/webdriverio/webdriverio/e2e/interop/wdio-reporter.e2e.js:2:22) {
  code: 'ERR_REQUIRE_ESM'
}

[christian-bromann]

you aware of what might be the cause?

I am aware and we are working on fixing it. I will rebase your PR once we have a green build again.

[christian-bromann]

I still would love to have a script to reproduce it to validate whether this fix is the best approach to resolve the original problem.

[erwinheitzman]

Hi @nextlevelbeard I didn't know this was changed so I love that you created this PR, I got some feedback which I feel might sound harsch but it's very objectively so nothing personal :)

I feel like there is no need for the ChromedriverError class, using the Error class suffices as the ChromedriverError aims to change take the message to either error, name or an empty string. Which should not be part of the class but should be the input (aka the message) and the rest works like it normally would.

However! I do see you use stacktrace instead of stack and if this is changed in Chromedriver, we shouldn't change how we handle this, instead we should report that stacktrace isn't a valid property name for the stacktrace (stack is) of an Error https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/Error instead.

[nextlevelbeard]

Hey @erwinheitzman thanks for having a look at this
As Christian mentioned ChromeDriver is throwing an Error that deviates from a standard Error because it is respecting the W3C spec. I believe it is in the interest of the project to fix this bug but also define this new Error type, give it a proper interface and have it inherit the Error class so that it can be understood/handled as any other error across the code base. At least that's my understanding. We are basically creating a standard error class by mapping the stacktrace to stack, error to name, and keeping the message property.

[christian-bromann]

@nextlevelbeard anything we can do to help get this over the line?

[nextlevelbeard]

@christian-bromann Just needs a bit of a refactor on the Error and finalize the tests.
Have some local changes, will look into this soon, haven't had much time for this lately.
Got a bit sidetracked because I was looking it seeing how to introduce and use the cause Error property. It needs ES2022for that but the type compilation is complaining when I change the tsconfigs around.

[christian-bromann]

Awesome, lgtm 👍