Re: Implicit Wait

Let me be the first to argue against this...

Implicit Waits are only designed to work with find elements. This is
something that the Selenium community added a while back and unfortunately
need even though a lot of us regret adding it? Why? People mix implicit and
explict waiting.

Now... implicit waiting for all commands? This feels like you want a way to
slow down commands? As you say, this will increase times that things are
running.We have recently adding #GetTimeouts which returns what timeouts
values are. People can always #GetTimeout, then #SetTimeout to 0, do
whatever and then #SetTimeout to the value from #GetTimeout.

I think that this is only going to bandaid timing issues and not really
solve them.

David




On 17 October 2016 at 20:32, Clay Martin <clmartin@microsoft.com> wrote:

> Hey Andreas,
>
> So giving it some thought, implicit wait in general is very hand wavy. We
> are assuming what commands the user would want to wait on with very
> subjective rules (must be an interaction that isn't straightforward with
> some form of user-input, such as Element Send Keys or Element Click). The
> issue this causes is that the user, for some commands, must implement their
> own retry logic, while for others they aren't required to do so.
>
> An example being Get Title. If a user has a script on the page that is
> delayed that changes the title after a set amount of time they must
> implement their own retry logic to test it. On the other hand if a user has
> a script that changes an elements Displayed property after a set amount of
> time and want to send keys, they don't need to implement their own retry
> logic because we, the implementations, will do it for them (for a subset of
> commands).
>
> I would argue that in addition to implicit wait (if not in replacement of
> it) we should have a flat wait. Something that just adds a defined wait for
> every command. At first you might argue this is stupid as it would
> drastically increase test times, but it offers developers a way to work
> around the weird oddities each of our implementations will have, especially
> if we aren't just using execute script for our commands but instead piping
> it into the code paths in our browser. There are a swathe of interop issue
> already that cause web developers pains, and I think allowing something
> like a flat wait to work around them would be helpful for various cases.
>
> Thoughts?
>
>
> -----Original Message-----
> From: Andreas Tolfsen [mailto:ato@mozilla.com]
> Sent: Saturday, October 15, 2016 5:16 AM
> To: public-browser-tools-testing <public-browser-tools-testing@w3.org>
> Cc: Clay Martin <clmartin@microsoft.com>
> Subject: 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.
>