Re: Implicit Wait

Hi Clay,

I think you’ve spotted a bug with the specification.

Clay Martin <clmartin@microsoft.com> writes:

> Thoughts on this? Should all commands be gated by implicit wait or
> was this determined and I just wasn't there/didn't hear about it. Our
> current impl seems to be spec compliant but wanted to call out the
> change nonetheless.

What does it _mean_ exactly that the driver should “[wait for
a] designated time before attempting to interact with the element”?
Are users expecting them to wait implicitly on the element
interactability check?

Gating _all commands_ with implicit waits seems wrong for a couple of
reasons.  The main reason is that the DOM is by definition
asynchronous, so we could only achieve the desired effect for a narrow
subset of the commands.  It is also not clear what conditions they
would poll on.

It would for example be impossible to make Get Title and Get Element
Style to have such checks because there is no explicit expression of
what the consumer is looking for.

If the idea is that it should only apply to the do-as-I-mean
(excluding the action API) interaction commands, i.e. every time
element interactability is checked, then that’s different, and I think
also in line with what existing (Selenium) implementations have been
doing.

This would leave us with two side-effects of setting the session
implicit wait timeout: it would wait a set duration before erroring on
not finding the element during element retrieval, and the same when the
interactability test continues to fail.

Received on Saturday, 15 October 2016 12:16:10 UTC