Re: Implicit Wait

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

-- Jason

On Mon, Oct 17, 2016 at 4:02 PM, David Burns <dburns@mozilla.com> wrote:

> I agree with James, we should be focusing on getting the spec done.
>
> Moving things about at this late stage is going to effect end users
> horrifically until we get people producing spec compliant implementations.
>
> David
>
>
>
> On 17 October 2016 at 23:14, James Graham <james@hoppipolla.co.uk> wrote:
>
>> On 17/10/16 22:59, Luke Inman-Semerau wrote:
>>
>>> I like Jason's proposal much better. Client side maintaining it (we can
>>> use some explicit waits under the hood for the user).
>>>
>>
>> I think that implicit waits are a bad idea. But before removing this from
>> the protocol please consider if this change is worthwhile given the
>> timetable for committing to protocol stability (~4 months). I think the
>> same criteria as the value wrapper changes should apply i.e. explicit buy
>> in from major implementors.
>>
>> With my geckodriver hat on I am concerned that there will be an
>> indefinite period where we will implement the hypothetical no-wait spec and
>> others will implement implicit waits and users will be convinced that
>> geckodriver is unreliable and broken.
>>
>> (For related reasons, and on a different topic, I am quite concerned
>> about the changes to new session handling. I think the PR is a win in the
>> abstract, but I am concerned at the size of the breaking change vs the
>> apparent preference of other implementors to prefer compatibility with
>> shipping selenium vs targeting the spec).
>>
>>
>>
>