Implicit waits are applied to find_element and find_elements operations only. They allow
to wait for an element to appear on the page. No operations (other than open) being
performed waits for the "next" page to be loaded. To avoid race conditions use proper
waiting strategy. Read [1] for examples.

[1] https://blog.mozilla.org/webqa/2012/07/12/how-to-webdriverwait/

Thanks for the clarification.  So, out of curiosity then, you say `find_elements` is
affected by implicitly_wait, does that mean that if `find_elements` finds 0 elements,
it retries until the wait timeout expires before returning an empty list?

`find_elements` might be a good compromise for me then. It would make things slower
when no elements are expected, but OTOH it might work as  a nice lightweight way for
me to get the implicit waits I want...

>> if `find_elements` finds 0 elements, it retries until the wait timeout expires before
returning an empty list?

Exactly so.

Aplogies for thinking out loud in what is probably the wrong place, but come to think
of it, find_elements won't work.  If, for example, I have a POST request that will
add an element to a table on the page, then I can't use find_elements to wait for the
second row to appear.


What this means is that, even for the absolute simplest of tests, I need to use some
kind of waitfor.  That's annoying*.  Surely webdriver can tell the difference between
a javascript-initiated GET or POST and a hyperlink/form-initiated one?  I mean, the
blog post says that's hard, but really?


* although not as annoying as having users moan and issue ill-informed feature requests
in bug reports.  Feel free to tell me to shut up.

Nobody can predict that "after a user clicks this button a new row should be added to
that table". But if you know this is expected result you have to wait for the expected
table size, ot for the size to be changed, or for the size to stop changing, or for
the activity indicator to disappear, or for something else. Remember there is no universal
solution to the halting problem [1]

[1] http://en.wikipedia.org/wiki/Halting_problem

Ah, the old halting problem, the bane of all our lives.  Pending a workaround for that,
here's my dream solution, which feels like it would solve my problems and feel intuitive
(surely if *I* find it intuitive, then everybody else on earth will too, right?)

1) webdriver can tell the difference between javascript-initiated stuff and non-javascript
browser interactions
2) so if we click a hyperlink which causes a browser GET, or we click a form submit
button that causes a browser POST,
3) webdriver will now invalidate its caches and wait for the DOM to load, so that my
next calls to, eg, find_elements, will pick up stuff from the new page.

But maybe my assumption at 1) is not correct?  Or maybe part 3) is way more complex
than I think? Or maybe the feeling is that, yes, it is all theoretically possible,
but it's too much effort to bother doing a bunch of work for a solution that works
well for non-javascript websites, given that the whole world is building javascript-heavy
sites these days?

Selenium does not wait for all AJAX interation to complete. Because it is asynchronous
in nature. A real user does not wait, she clicks another button as soon as it is available.
Despite th fact that "some AJAX requests are not processed yet, and the DOM is still
rebuilding". It is not a user problem. And Selenium simulates such a user :)

Thanks for persisting with the conversation, I appreciate it.

I was talking about non-AJAX requests, sorry that wasn't clear.  Can Selenium tell
the difference?  And, if so, could it do some more "intuitive" things in the case of
non-Ajax/normal requests?  ie, wait until the new page has properly loaded?

You welcome to the selenium dev list [1] with questions about design decisions, the
issue tracked is not the best place for discussions.

[1] https://groups.google.com/forum/#!forum/selenium-developers