Have you read the Contributing Guidelines on issues?
WebdriverIO Version
=9.6.2
Node.js Version
20
Mode
Standalone Mode
Which capabilities are you using?
capabilities: [{
browserName: 'chrome'
}],
What happened?
when checking waitForDisplayed({reverse:true}) if the element isn't present it errors and fails
What is your expected behavior?
It should not error out
It works in versions <9.6.2
My guess would be something in this PR #14103
How to reproduce the bug.
await browser.url(`https://v4.mui.com/components/modal/`)
const button = await $('button=Open Modal').getElement();
const modal = await $('h2#simple-modal-title').getElement();
await expect(modal).not.toBeDisplayed();
await button.click();
await expect(modal).toBeDisplayed();
await browser.action('pointer').move({ x: 0, y: 0 })
.down({ button: 0 }) // left button
.perform()
await modal.waitForDisplayed({ reverse: true });
Relevant log output
[0-0] Error in "My Login application.should login with valid credentials"
Error: waitUntil condition failed with the following reason: Can't call getElementCSSValue on element with selector "h2#simple-modal-title" because element wasn't found
at implicitWait (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\build\node.js:523:13)
at async <anonymous> (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\build\node.js:544:12)
at async Element.elementErrorHandlerCallbackFn (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\build\node.js:7944:28)
at async Element.wrapCommandFn (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\node_modules\@wdio\utils\build\index.js:893:23)
at async Element.getPropertyCSSValue (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\build\node.js:6143:10)
at async Element.getCSSProperty (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\build\node.js:6103:21)
at async Element.wrapCommandFn (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\node_modules\@wdio\utils\build\index.js:893:23)
at async Element.elementErrorHandlerCallbackFn (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\build\node.js:7921:24)
at async Element.wrapCommandFn (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\node_modules\@wdio\utils\build\index.js:893:23)
at async Promise.all (index 1)
---
at <anonymous> (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\build\node.js:5577:17)
at async Element.wrapCommandFn (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\node_modules\@wdio\utils\build\index.js:893:23)
at async Element.elementErrorHandlerCallbackFn (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\build\node.js:7921:24)
at async Element.wrapCommandFn (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\node_modules\@wdio\utils\build\index.js:893:23)
at async Element.wrapCommandFn (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\node_modules\@wdio\utils\build\index.js:893:23)
at async Element.elementErrorHandlerCallbackFn (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\build\node.js:7921:24)
at async Element.wrapCommandFn (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\webdriverio\node_modules\@wdio\utils\build\index.js:893:23)
at async Context.<anonymous> (C:\Users\josh\Documents\git\wdio-test\e2e\test\specs\test.e2e.ts:14:9)
at async Context.executeAsync (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\@wdio\utils\build\index.js:1013:20)
at async Context.testFrameworkFnWrapper (C:\Users\josh\Documents\git\wdio-test\e2e\node_modules\@wdio\utils\build\index.js:1084:14)
Code of Conduct
Is there an existing issue for this?
Have you read the Contributing Guidelines on issues?
WebdriverIO Version
Node.js Version
20
Mode
Standalone Mode
Which capabilities are you using?
What happened?
when checking
waitForDisplayed({reverse:true})if the element isn't present it errors and failsWhat is your expected behavior?
It should not error out
It works in versions <9.6.2
My guess would be something in this PR #14103
How to reproduce the bug.
Relevant log output
Code of Conduct
Is there an existing issue for this?