- From: Andreas Tolfsen <ato@mozilla.com>
- Date: Tue, 18 Oct 2016 13:04:11 +0100
- To: public-browser-tools-testing <public-browser-tools-testing@w3.org>
- Cc: Clay Martin <clmartin@microsoft.com>, Luke Inman-Semerau <luke.semerau@gmail.com>, David Burns <dburns@mozilla.com>
Clay Martin <clmartin@microsoft.com> writes: > My main issue with implicit wait is that it’s implicit, which means > somewhere we drew a line in the sand and said “this is the correct > option” for the end user. > > Also visibility is a very broad term, one which we have struggled to > define before and still have yet to do successfully (in fact I don’t > think there is anyone who has) as it has to take into account > Displayed, in view, not obscured by something else and actually > visible. We define keyboard interactability and pointer interactability. Those are the two conditions, in addition to element retrieval, that we can realistically test for in an implicit wait. > If we can be explicit about what commands must run in a retry loop > for the duration of implicit wait and either return on first success > or when the timer ends and that’s the only threshold I think it makes > sense. I have sympathy for Jason’s proposal to not do implicit waits, but I’m not convinced we can realistically change that now. > The moment we try to define visibility though we get into murky, > unspeccable waters imo. Intersection observer is trying to tackle > visibility in some ways (and might be another data point in what > really is visible) but even that isn’t fullproof or dealing with our > core issue (what an end user would consider visible). We don’t try to define visibility at all.
Received on Tuesday, 18 October 2016 12:04:43 UTC