RE: Implicit Wait

Responses inline

From: David Burns [mailto:dburns@mozilla.com]
Sent: Monday, October 17, 2016 2:35 PM
To: Clay Martin <clmartin@microsoft.com>
Cc: Andreas Tolfsen <ato@mozilla.com>; public-browser-tools-testing <public-browser-tools-testing@w3.org>
Subject: 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.
[clmartin]: This is fine but currently at least it seems to be for more than just Find Element commands. The bug I listed in Chrome works, because Chrome continues to try sending keys for the duration of the Implicit Wait specified even though Send Keys is not a Find element command.
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.
[clmartin]: It would mask issues but for all browsers. We’d be naïve to think that all of our products won’t have hiccups across the various components used in commands (although if you’re just using DOM APIs for all of your command implementations, due to interop work from all major vendors, this may be lessened). Every interop bug we have is another potential workaround for a tester. The problem is that while we try to fix them people are having to implement their own workarounds for the various issues. I guess my main point is as a developer/tester you have to test across all browsers, Chrome/Firefox/Safari/Edge and mobile skews as well, and they all have their own quirks. As more get added this will only worsen. Having a way to standardize command response times might be nice in this regard. Depending on how contentious this is though we could push the debate to a V2 timeframe.
I think that this is only going to bandaid timing issues and not really solve them.
[clmartin]: That’s fair, but I don’t think giving the developer a workaround would be a bad idea. It’s not required to be used but could be there for those who want it.
David



On 17 October 2016 at 20:32, Clay Martin <clmartin@microsoft.com<mailto: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<mailto:ato@mozilla.com>]
Sent: Saturday, October 15, 2016 5:16 AM
To: public-browser-tools-testing <public-browser-tools-testing@w3.org<mailto:public-browser-tools-testing@w3.org>>
Cc: Clay Martin <clmartin@microsoft.com<mailto:clmartin@microsoft.com>>
Subject: Re: Implicit Wait

Hi Clay,

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

Clay Martin <clmartin@microsoft.com<mailto: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.