Re: Implicit Wait

-1 to global waits, additional scope of implicit waits to "all commands"
 (example getTitle makes no sense, every page has a title and can return
that immediately, a user doesn't pass in the expected title they want to
match to the driver).

-1 for a global 'wait' during every command... nopety nope nope nope. This
is a nightmare for helping users troubleshoot their issues... since truly
only novice users would dare to set such a crazy thing. Users still ask for
a 'setSpeed' that RC / IDE has, which does exactly this. Again.... nope!


+1 for implicit waits to wait for visibility of elements when trying to do
subset of element actions:  sendKeys, click, getText.  (that's all I can
think of that 'should' have implicit waits beyond finding the element). I
believe users expect these, which I think we should allow. But we should be
very explicit on which command adheres to the implicit wait.

Any advanced user interaction should *not* take implicit wait into
consideration. We really want to steer users toward explicit waits. If they
want advanced interaction, they'll need explicit.

-Luke

On Mon, Oct 17, 2016 at 2:34 PM, David Burns <dburns@mozilla.com> wrote:

> 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.
>>
>
>