Fix FluentWait so it completes in more cases. #7692
Conversation
|
@barancev Could you please review this PR? |
FluentWait could potentially never complete when the condition passed to it made no progress (either because it fall into an infinite loop or waiting for a resource or response over network). Fixes SeleniumHQ#7494
Hanged is a dodgy expression. Fixes SeleniumHQ#7494
|
@barancev : could you please give an insight on how PRs get processed? I can imagine that you guys are extremely busy and 20 days is not the end of the world to wait for a PR to be reviewed. It's just killing my excitement to try to do any further contribution not to know what to expect and when. |
|
I appreciate this is not the best experience with the project. We really are very grateful for the PR. Right now, there are two people active in the java tree: @barancev and @shs96c (me!), and both of us are a little overwhelmed. Thank you for your patience, and the nudge to get things going. The review process is a little ad-hoc, but I'll speak for myself. I try and scan the backlog of PRs when I get a chance (which, I'll be honest, hasn't been often recently). If I can review it quickly, and merge it, I'll do that. If the PR requires a longer review, I tend to set it aside for a time when I have enough time to do a proper job. A gentle nudge on the Slack channel is a great way to get one of us to focus on your PR if we're being super-slow. Yes, I know that this isn't the best way to run a project, but I'm generally working on Selenium in my free time, and there's not been a lot of that lately. :( |
|
Thank you @shs96c for the insight and for your work on this project. |
|
|
|
I'll try to resolve the test failures |
|
Merged as 51de536, thank you! |
|
Sorry to say this, but we decided to return back to the legacy (blocking) implementation after clients complains. It appears that many people use suboptimal approach to manage WebDriver instances using TreadLocal variables. And running conditions in a separate thread makes them lost their driver. So we decided to revert this change in favour of backward compatibility. People who want to use FluentWait for potentially blocking conditions should create an alternative class that uses a sort of ExecutorService, and this PR can be used as a draft for this new class. |
FluentWait could potentially never complete when the condition
passed to it made no progress (either because it fall into an
infinite loop or waiting for a resource or response over
network).
Fixes #7494
Xin the preceding checkbox, I verify that I have signed the Contributor License Agreement