Re: Implicit Wait

The idea with implicit waits was to wait for find element, and also for any command that changed the state of the element (send keys, click, etc)

The rationale for it is that many testers don't really understand when the DOM of their app changes, and so aren't aware of when to use an explicit wait. The rise of things like Sauce Labs also meant that we wanted to minimise round trips, so pushing simple waits up to the remote end makes a lot of sense. 

The implicit wait works in two ways. For find element, Selenium waits for the presence of the element on the DOM. For interaction commands, we wait until the element is interactable. Again, the reason for this is because people may not actually know when to use an explicit wait. 

Despite being a massively requested user feature (which is why we added it), the advice of the selenium team has always been to try and minimise the timeout used (preferably to 0). Advanced users get this right quite often. Inexperienced or untrained users find this enormously useful, and so use it extensively. 

Obviously, it would be nice if the spec mapped cleanly down to these semantics, since this will reduce the number of specious bug reports from existing users. 

Simon

Sent from my iPhone

> On 15 Oct 2016, at 00:58, Clay Martin <clmartin@microsoft.com> wrote:
> 
> Hey all,
>  
> Going through our bug backlog and came across an interesting interop issue. Per the specification implicit wait should only account for element retrieval commands
> https://w3c.github.io/webdriver/webdriver-spec.html#dfn-set-timeouts
>  
> Our section on retrieving elements details only specific commands
> https://w3c.github.io/webdriver/webdriver-spec.html#element-retrieval
>  
> It seems though, as per a unit test I was debugging, that at some point it wasn’t used for just FindElement-based commands but all commands sent to the driver. I wanted to determine if the specification in this instance was an intentional change from that or not. The bug I’m investigating is this:
> https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/3900872/
>  
> Initially I thought our impl might be choking on the 5000.0 for ms (weird to me to send decimal values for ms), but we seemed to return fine from that. The reason why Edge fails in this case is that we require focus before sending keys (per the specification). When the reveal element gets clicked, there is a 1000ms delay before the revealed element gets displayed. As this isn’t an element location command, we fire the next command as soon as Click() returns. This means we go to send keys to a hidden element, which then fails as we can’t focus a hidden element and we get the bug which mistakenly assumes we aren’t respecting implicit wait.
>  
> 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.
>  
> Thanks,
> Clay