[🚀 Feature]: Allow specifying a callable for the message argument in WebDriverWait.until / until_not.
Feature and motivation
I would like to construct an error message using the driver in the message argument of WebDriverWait.until / until_not when an error occurs.
Currently, it is necessary to use a try-catch structure, but if the message argument could accept a function, I believe it would allow for more readable code.
Usage example
WebDriverWait(driver, 10).until(lambda x: x.find_element(By.ID, "someId"), lambda x: f'Message: {x.current_url}')
@moeyashi, thank you for creating this issue. We will troubleshoot it as soon as we can.
Info for maintainers
Triage this issue by using labels.
If information is missing, add a helpful comment and then I-issue-template label.
If the issue is a question, add the I-question label.
If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.
If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C),
add the applicable G-* label, and it will provide the correct link and auto-close the
issue.
After troubleshooting the issue, please add the R-awaiting answer label.
Thank you!
This issue is stale because it has been open 280 days with no activity. Remove stale label or comment or this will be closed in 14 days.
This issue is looking for contributors.
Please comment below or reach out to us through our IRC/Slack/Matrix channels if you are interested.
Could just be this, right?
final_message = message() if callable(message) else message
Won't this be a breaking considering the default value of message is empty string?
until(self, method: Callable[[D], Union[Literal[False], T]], message: str = "")
Default shouldn't need to change. Dynamic typing means you can pass in either type and then the code can check which it is and handle appropriately.
Hi, @moeyashi.
This is related to code in the Support packages. The support packages contain example code that many users find helpful, but they do not necessarily represent the best practices for using Selenium, and the Selenium team is not prioritizing work on them right now. This doesn't mean that we won't ever work on them, but it is not on our roadmap as we push to release Selenium 5.
We actively encourage people to create their own wrapper and helper code that makes sense for them. If you have any questions, please contact us
This issue has been automatically locked since there has not been any recent activity since it was closed. Please open a new issue for related bugs.