Re: Implicit Wait

I like Jason's proposal much better. Client side maintaining it (we can use
some explicit waits under the hood for the user).

On Mon, Oct 17, 2016 at 2:52 PM, Clay Martin <clmartin@microsoft.com> wrote:

> Agreed Jason.
>
>
>
> *From:* Jason Leyba [mailto:jleyba@google.com]
> *Sent:* Monday, October 17, 2016 2:50 PM
> *To:* Luke Inman-Semerau <luke.semerau@gmail.com>
> *Cc:* David Burns <dburns@mozilla.com>; Clay Martin <
> clmartin@microsoft.com>; Andreas Tolfsen <ato@mozilla.com>;
> public-browser-tools-testing <public-browser-tools-testing@w3.org>
> *Subject:* 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.
>
>
>
>
>
>
>