- From: Luke Inman-Semerau <luke.semerau@gmail.com>
- Date: Mon, 17 Oct 2016 14:59:26 -0700
- To: Clay Martin <clmartin@microsoft.com>
- Cc: Jason Leyba <jleyba@google.com>, David Burns <dburns@mozilla.com>, Andreas Tolfsen <ato@mozilla.com>, public-browser-tools-testing <public-browser-tools-testing@w3.org>
- Message-ID: <CAL97Zu4diRioOwFXVs+LM2wViHJb53ApMGmmS27i5be5Hw5dBA@mail.gmail.com>
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. > > > > > > >
Received on Monday, 17 October 2016 21:59:57 UTC