Add _WD_WaitScript function

[ye7iaserag]

Pull request

Proposed changes

Add a new function that takes JavaScript code and waits until the code returns true

Checklist

Put an x in the boxes that apply. If you're unsure about any of them, don't hesitate to ask. We are here to help!
This is simply a reminder of what we are going to look for before merging your code.

• [x] I have read and noticed the CODE OF CONDUCT document
• [x] I have read and noticed the CONTRIBUTING document
• [x] I have added necessary documentation or screenshots (if appropriate)

Types of changes

Please check x the type of change your PR introduces:

• [ ] Bugfix (change which fixes an issue)
• [x] Feature (change which adds functionality)
• [ ] Code style update (formatting, renaming)
• [ ] Refactoring (functional, structural)
• [ ] Documentation content changes
• [ ] Other (please describe)

What is the current behavior?

New function

What is the new behavior?

New function

Additional context

Add any other context about the problem here.

System under test

Please complete the following information.

• OS: [e.g. Windows 10]
• OS Arch.: [e.g. X64]
• Browser [e.g. chrome]
• Browser version [e.g. 110.0]

[Danp2]

@ye7iaserag Thanks for your submission. A few questions for you --

• Can you provide a short code snippet (ie: something that can be used in wd_demo's UserTesting function) that demonstrates the proper usage of this function?
• Should the function perform any validation of the provided Javascript? For example, should an error be returned if the JS doesn't begin with a "return"?

[Danp2]

Another thought would be to modify your submission as follows --

• Rename the function to _WD_ExecuteScriptEx, since it is a wrapper for _WD_ExecuteScript
• Add an optional parameter $vWaitReturn, which should default to Default
• When $vWaitReturn isn't equal to Default, perform the comparison check on the scripts return value against $vWaitReturn, which allows for more comparisons than just true.

IMO, these changes would make your function more dynamic / useful to the user.

[ye7iaserag]

• Regarding the code snippet no worries, I'm on it.
• Validation: You are right maybe a simple StringRight call can be used here.
• Regarding function name, I tried to be as close to the other libs like puppeteer that uses waitForFunction for such case, wile I do not think _WD_ExecuteScriptEx would reflect what the function is actuallu doing, it's close in functionaly to _WD_WaitElement, so I followed the same convention.
• I don't think $vWaitReturn would extend existing functionality, since you can write any condition/expression you want in the JS script, any thing that you would add in $vWaitReturn can be added directly in script, in fact it would limit the existing functionality because then you wouldn't be able to and/or conditions (except for true/false values)

Please let me know what you think of the above points.

[Danp2]

Hi @ye7iaserag,

The current implementation only works with a True/False result from the Javascript, and "success" is only achieved when True is returned. I was suggesting that the function could be more powerful if it allowed other return values to indicate success. For example --

• Loop until the result is False instead of True
• Loop until result is a specific numeric value
• Etc

Let me know if this helps explain why I suggested adding $vWaitReturn.

Regards, Dan

[ye7iaserag]

But you can manipulate that in the JS expression, still don't get your point

an example of usage is:

_WD_WaitScriptTrue($sSession, 'return window.getComputedStyle(document.querySelector("div#div1")).getPropertyValue("opacity") === "0" || document.querySelector("div#div2").innerText === "Completed!"')

and in the same way you can achieve any required result by manipulating the expression an example would be changing the above code to be:

_WD_WaitScriptTrue($sSession, 'return window.getComputedStyle(document.querySelector("div#div1")).getPropertyValue("opacity") === "0.5"')

Let me know if we are still not on the same page

[Danp2]

OIC. That makes sense now. Thanks for clarifying.

[Danp2]

Validation: You are right maybe a simple StringRight call can be used here.

I think you meant StringLeft, correct?

I do not think _WD_ExecuteScriptEx would reflect what the function is actuallu doing, it's close in functionaly to _WD_WaitElement, so I followed the same convention.

Agreed. What about dropping the True from the function name? It sticks out like a sore thumb IMNSHO.

[ye7iaserag]

I agree on both points

[ye7iaserag]

I think I have to remove the check for the return string on the left of script. One use cases that I had going was something like

let name = document.querySelector(".success");if(!!name){return name.innerText.includes("' & $usernameValue & '")}else{return false;}

Now this fails It still can be written in the form:

return document.querySelector(".success") && document.querySelector(".success").innerText.includes("' & $usernameValue & '")

But is restrictive

[Danp2]

@ye7iaserag It's fine if you want to remove that check.