feat(waitFor): update various waitFor options to be a single boolean

[dgozman]

Default waitFor: true now waits for element to exist, stop moving and become a hit target in input actions, and only only exist in non-input actions.

Note that this removes the ability to wait for visible from fill() and select() methods.

[pavelfeldman]

At the very minimum you should throw upon old options being passed

[dgozman]

At the very minimum you should throw upon old options being passed

I already do.

[pavelfeldman]

• Why not to leave the visible option?

• How do I wait for node to be hidden?

• When I say page.click({waitFor:{exists:false}), does it mean I wait for it to hide or I don't wait? It is not clear whether I should be clearing static and hittarget bits if I just don't want to wait for anything. In this unlikely-to-occur case, I would prefer page.click(waitFor:nowait).

It seems like we have at least three input wait strategies:

• Wait by all means until it appears, stops and is clear to click. Time out if that did not happen. This option is most convenient, but it fails with a timeout. Since we know timeout is not a thing in the cloud, we need better signals to fail upon. Like no pending XHRs, timers or animations.

• Don't wait at all, assert that it is there and receives the click, throw if it isn't. Resolves immediately.

• Something in the middle for efficiency? Wait for dom, but don't wait for visible, hit target or static? Does it really make it more efficient? Do I ever want it?

[pavelfeldman]

evetns

[dgozman]

• Why not to leave the visible option?

visible is not clearly defined, and is superseded by static + hittarget.

• How do I wait for node to be hidden?

page.waitForSelector({visibility: 'hidden'}). That said, I would prefer a separate method like page.waitForSelectorHidden or page.waitForSelectorMissing.

• When I say page.click({waitFor:{exists:false}), does it mean I wait for it to hide or I don't wait?
  This means don't wait.

It is not clear whether I should be clearing static and hittarget bits if I just don't want to wait for anything. In this unlikely-to-occur case, I would prefer page.click(waitFor:nowait).

Sounds reasonable.

• Something in the middle for efficiency? Wait for dom, but don't wait for visible, hit target or static? Does it really make it more efficient? Do I ever want it?

I don't think efficiency is a concern here. The usecase I can think of is "I would like to assert that it's clickable in the state the page is in". That would be the "no wait" scenario. If we don't find compelling usecases for middle ground, we can go with wait: boolean option instead. WDYT?

[pavelfeldman]

If we don't find compelling usecases for middle ground, we can go with wait: boolean option instead. WDYT?

Yes, this is what I was hinting at. With respect to present API, it would mean that waitForVisible gains waitForInterqctable semantics and becomes waitFor. It can be boolean today, and we will be able to say boolean|object in the future to include all your fine-grained bits. I don't think we should commit to bits in v1, but we leave ourselves this option.

[dgozman]

Please take another look, using a boolean now.