Combining implicit wait and explicit wait together results in unexpected wait times

0
0

My two scenarios –

1) First

@driver.manage.timeouts.implicit_wait = 30
@wait = Selenium::WebDriver::Wait.new(:timeout => 45) # Time greater than implicit
@wait.until {@driver.find_element(:tag_name => "body").text.include?("hey")}

Which gives the driver 45 seconds to search for the text(which is expected)

2) Second

@driver.manage.timeouts.implicit_wait = 30
@wait = Selenium::WebDriver::Wait.new(:timeout => 5) # Time less than implicit
@wait.until {@driver.find_element(:tag_name => "body").text.include?("hey")}

This now gives the driver 30 seconds to search for the text(not expected)

Is there a way to make selenium wait only for the explicit wait time and not for the greater of the two?

Note – Not declaring the implicit wait time is not an option, cause I cannot afford to let selenium hang each time the driver is unable to find something.

Using Selenium version 30, windows, ff

  • You must to post comments
0
0

Don’t mix implicit and explicit waits. Part of the problem is that implicit waits are often (but may not always be!) implemented on the “remote” side of the WebDriver system. That means they’re “baked in” to IEDriverServer.exe, chromedriver.exe, the WebDriver Firefox extension that gets installed into the anonymous Firefox profile, and the Java remote WebDriver server (selenium-server-standalone.jar). Explicit waits are implemented exclusively in the “local” language bindings. Things get much more complicated when using RemoteWebDriver, because you could be using both the local and remote sides of the system multiple times.

This is how that would work: local code -> Java remote server -> local Java language bindings on the remote server -> “remote” component like the Firefox extension, chromedriver.exe or IEDriverServer.exe. It’s even more complex in the grid case, since there could be other hops in between.

Thus, when you try to mix implicit and explicit waits, you’ve strayed into “undefined behavior”. You might be able to figure out what the rules of that behavior are, but they’ll be subject to change as the implementation details of the drivers change. So don’t do it.

You shouldn’t be experiencing “hangs” when an element can’t be found if you’re not using implicit waits. The driver should throw a NoSuchElement exception immediately.

  • You must to post comments
Showing 1 result
Your Answer
Post as a guest by filling out the fields below or if you already have an account.
Name*
E-mail*
Website