Re: Implicit Wait

Inline.

On Mon, Oct 17, 2016 at 2:44 PM, Luke Inman-Semerau <luke.semerau@gmail.com>
wrote:

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

​If we want​ to steer users toward explicit waits, why include implicit
waits in the spec at all? Existing clients can include an implicit wait
shim for the find commands.


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