Re: Implicit Wait

+1 to Luke's points

Sent from my iPhone

> On 21 Oct 2016, at 19:57, Simon Stewart <simon.m.stewart@gmail.com> wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On 18 Oct 2016, at 00:50, Jason Leyba <jleyba@google.com> wrote:
>> 
>> 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.
>> 
> 
> Because it's extensively used by people, and there are more local ends than remote ends. Worse, not all the local ends understand shimming and don't communicate with the selenium project (look at the plethora of JS bindings)
> 
> We want a consistent user experience, else why have a spec at all. The globally simplest way to achieve that is to impliment waits in the remote end. 
> 
> Simon
> 
>>> -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.
>>>> 
>>> 
>>