Re: Implicit Wait

I am not a fan of the implicit wait system. It's completely redundant with some basic polling logic in a client library.
They are maybe the most obnoxious inversion between driver and library responsibility in the entire protocol.

(I am as not familiar with the legacy considerations as the Mozilla folks are, but...)

It should be possible today to shim from implicit-wait to no-wait transparently in a client library by setting implicit wait
to zero and shaking out logic bugs in the library well before any driver implementation removes implicit wait.

As an implementor, I am eager to make the driver less stateful by getting rid of implicit waits. That said, I
have to support them anyway in the legacy protocol, so users can always fall back if they can't upgrade the client library
or the client library doesn't support W3C.

	-Brian

> On Oct 18, 2016, at 11:16 AM, James Graham <james@hoppipolla.co.uk> wrote:
> 
> On 18/10/16 18:02, Jason Leyba wrote:
>> Let me get this straight: implicit waits are now inconsistently defined
>> and implemented, and there doesn't even appear to be strong support for
>> whether users should use this feature at all. So expanding the spec to
>> cover all the possible scenarios for implicit waits is less work and
>> less complicated than simply removing the feature? OK
> 
> It certainly seems less complicated to spec. But the outstanding question is whether anyone would implement those semantics or would in fact continue to implement the selenium semantics (whatever those are, and to a greater or lesser degree). If you can get all remote end implementors to explicitly agree to drop the idea of implicit waits, I will be OK with it for geckodriver, but I fear the test breakage this will cause.
>

Received on Tuesday, 18 October 2016 22:46:08 UTC