#webdriver tutorial

The general case of determining when a page is done loading is a variation of the halting problem. When you ask Webdriver to load a page, it does block briefly while it runs through its own algorithms to figure out when the page is done loading. But, it being the halting problem and all, they obviously can't solve it for all the cases.

my $d = Selenium::Firefox->new; $d->get($tricky_slow_loading_page); # this will throw when the element isn't present my $text = $d->find_element_by_css('div')->get_text

The problem with putting in a sleep before attempting to find the element is that it will usually work, but maybe one time in twenty it will fail, and it won't be immediately apparent why it failed, especially months down the line. What we want is a method that reliably and consistently waits exactly until the element in question is ready. We don't want to wait any longer than necessary, so a long explicit sleep is out, but we don't want to go early, or else we'll get exceptions all over the place. wait_until lets us get pretty close to this ideal behavior:

# wait_until will also catch dies and croaks my $elem = wait_until { $d->find_element_by_css('div') }; if ($elem) { say 'Text: ' . $elem->get_text; } else { say 'We waited thirty seconds without finding css=div'; }

wait_until takes a block and an optional hashref of arguments. It wraps the block execution in a try/catch from Try::Tiny. By default, it will run for thirty seconds, sleeping one second between iterations. If at any point the block returns something true, it immediately returns that value as its result. Note that wait_until expects a block that is generally NON-blocking, so if webdriver has an associated timeout, like the implicit wait timeout for finding elements, you'll want to set it to a second or less if you've increased it. The exact number of iterations will depend on how long the block takes to execute.

To be clear, if your implicit_wait_time is 31 seconds, and you put a find_element inside a wait_until, we'll run it once, Webdriver itself will block for 31 seconds, and by the time we get control back in our wait_until block, the timeout will have expired, and we'll return control to your script after executing exactly one find_element. (This may be the behavior you desire - but just make sure you're doing it on purpose!)

my $d = Selenium::Firefox->new; $d->set_implicit_wait_timeout(30000); my $one_iteration = wait_until { $d->find_element('this is blocking', 'css') };

You can also use wait_until to have your test block until the element is visible, or some other boolean property:

my $visible_elem = wait_until { $d->find_element_by_id('eventually-visible')->is_displayed };

Finally, as mentioned, wait_until wraps everything in a try, so if the BLOCK you passed in does die, it'll get demoted to a warn. This means you MUST check the return value of wait_until. Normally, Selenium::Remote::Driver will croak when we run into something we don't understand 1. Since we're only warning, it's possible you may get into some weird territory if you make assumptions about the return value. Honestly, I'm still not sure about this behavior - perhaps it makes sense for wait_until to die if the expected value never returns true.