-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use waitForSelector instead of until #10852
Conversation
45ab932
to
fed5bdb
Compare
fed5bdb
to
db0f57e
Compare
Builds ready [db0f57e]
Page Load Metrics (622 ± 56 ms)
|
test/e2e/webdriver/driver.js
Outdated
case 'visible': | ||
return await driver.wait(until.elementIsVisible(element), timeout); | ||
default: | ||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this throw? I'm having trouble imagining how this could be useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably, yeah.
await driver.wait(until.elementTextMatches(balances[0], /1/u), 15000); | ||
const balance = await balances[0].getText(); | ||
|
||
assert.equal(balance, '1'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the intent of this assertion was to ensure this test doesn't pass if the balance is a number containing the digit 1 (e.g. 1.51
, 100
, etc.). It might be worth preserving this assertion, both here and below where a similar assertion was removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will do! Thanks
I think this is the last step in completing #10755 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Builds ready [7a49c63]
Page Load Metrics (561 ± 32 ms)
|
This PR completes the abstraction of the until utility from Selenium.
When refactoring to use the work completed in #10844 I ran into a few cases where I believe a race condition made tests flakey at best. The waitForSelector method when passed the
{ state: 'detached' }
options bag would try to find an element with the provided selector and wait for it to be removed from the DOM. However, in every case we used the detached flag we are triggering the close of the modal/element before we callwaitForSelector
. If the modal is removed from the DOM before the waitForSelector is called then it would timeout.To fix this I have added another item into the Element API wrapper that matches the API from playwright. The new utility method is
waitForElementState
. It works in much the same way as the page levelwaitForSelector
but the element handle is stable and the race condition is abated. I have left the detached support in waitForSelector because it exists in the playwright APi that it is modeled after.