Missing commands : waitFor...

[rdcdt1]

hi, thank for your work .
With the old ide there was a command waitFor... , it would be nice to see it back, because 'pause' command cannot manage correctly asynchronous event.
Thank you

[Jongkeun]

I think #102 will be the answer to your question.

[rdcdt1]

sorry i reddit my issue it all waitfor commands

[corevo]

Its exactly the kind of things we want to avoid,
Unless there is absolutely no way for us to wait automatically for something to happen, only then we will consider adding a specific waiting mechanism for that.
The idea is that we want scripts to focus on user interaction with the browser, and not the implementation details (wether a click is sync or async).
And so we have a complex waiting mechanism, designed to wait for certain async events to happen (network requests etc...), and then we wait another grace period (30 seconds) for the element to appear.
If I sum it up, the way the IDE is waiting is as follows:

• waits for page to load
• waits for page to render (all nodes to render)
• waits for ajax requests to finish
• waits for the page to stabilize after ajax are done
• if all else fails, waits another 30 seconds (or the least that is required) if necessary

To introduce a failure, you would need to have an async task, that doesn't send any ajax requests, and lasts for more than 30 seconds.
If there is a failure, there may be two reasons, the automatic waiting mechanism failed, in which case we will fix it.
Or it is something that the waiting mechanism doesn't (and shouldn't) cover, whichever the case, I'd love to see the example where it fails, to understand how best to tackle it.
I'm not saying we won't add any waiting commands ever; It's just that I haven't seen the case for it, just yet.

[YglesEyes]

Hello Corevo,
(rdcdt1 is our apprentice, I continue the discussion with you to explain our specificities)

I develop embedded Web MMI with WebSocket, some systems are very slow to answer for several reasons:

• Backend are very slow (because they have a RT part and backend is not a RT process or just not powerful system) and/or have very slow network (for several reasons)
• Backend can be temporarily disconnected and send the result of an user action later
• Backend has to configure and other system before sending a new status after an user action
• Backend can be event-driven, it wait for an answer after a request (for example: ask to a robot to do something, wait for running state then wait for finish state)
• On page loading, we load quickly all nodes but we parameterize them after and MMI is not completely
  ready (with websocket)

In summary, we don't use AJAX but websocket, we are event-driven, a 'pause' command is not a reliable wait system because we are on embedded system.

I know it's a specific case but embedded Web MMI are more and more used in industry and we need to do several tests to qualify our system (customer request).

I didn't check yet all differences between v2.9.1 and this one but if you are interesting to develop new functionality which can answer to embedded specificities, I will be happy to share with you our feedback but if it is not in your scope I understand.

Regards,

Ygles

[corevo]

What waiting mechanism do you use now?
waitForElementPresent?

[YglesEyes]

Used by myself:
waitForElement[Not]Present
waitForAlert[Not]Present
waitFor[Not]Visible

By our test team:
waitFor[Not]Editable
waitFor[Not]Checked
waitFor[Not]SelectedValue

Other command:
deleteAllVisibleCookies

[barancev]

I vote for adding waits as soon as possible.

Yes, implicit waits made obsolete waitForPageToLoad and waitForElementPresent commands. But not the other ones.

To click an element you often have to wait until it's visibility, not presence. To fill an input you often have to wait until it becomes editable, not present. To wait for a result of an action you have to wait for changes in element properties -- elements can become visible/invisible, they can change text or style.

We need all sorts of waits to deal with moders single page applications that never reload pages. Implicit waits are ineffective for such applications.

[corevo]

I talked about it yesterday with @tourdedave on the phone.
It's definitely something we've decided to prioritize, any wait that isn't waitForPageToLoad or waitForElementPresent, will be added, we'll need to decide on a first batch of commands.

[98gmarquee]

waitForVisible is one I use all the time. Not that should sway your prioritizing decision. :)

[luquitia]

I believe these are delivered with latest version 3.4.0 (available Oct 5), for these commands (copied from another ticket, provided by @corevo): wait for element editable, wait for element not editable, wait for element present, wait for element not present, wait for element visible, wait for element not visible

The "visible" waits are very useful! 👍

So I think this issue can probably be closed.

[tourdedave]

Closing this issue since no additional waitFor command request have been made.