There really shouldn’t be any difference. I am using ‘Wait For Element Present’ in version 8.6.0 and my test fails, while it worked in version 8.5.5. I give 50 seconds to wait, but it doesn’t. My test case includes a test that requires an incoming phone call. I have to wait for the call to come in and then I can click on it.
Could be that this keyword is using a library shared with the other two we know are changed, e.g WebUiCommonHelper so there is a common point of failure for more keywords than known at this moment.
the diff of WebUiCommonHelper.groovy v8.4.1 and v8.6.0
733c733
< List<WebElement> foundElements = findElementsByDefault(testObject, timeout);
---
> List<WebElement> foundElements = findElementsByDefault(testObject, 0);
899a900
> testObject.setSelectorMethod(SelectorMethod.CSS);
960a962,966
> } else {
> if (isSwitchToParentFrame) {
> switchToDefaultContent();
> }
> break;
which makes me think the devs should look also at:
"modifiedFiles": [
"com/kms/katalon/core/webui/common/CssLocatorBuilder.java",
altough i do not understand why now is enforced to ‘default’ and in addition to css.
it should be based on whatever the tester choosed for his TO.
Well, I would pass this to the developers for further studies.
Hi guys,
I have the answer from the katalon support:
“The development team has informed me that this issue will be included in Katalon version 8.6.1, which is our next release.ETA is around mid - end of May.”
But I reported only waitForElementNotPresent, but I think if they will repair this bug, it will also fix other issue with waits commands.
Have a nice day and thanks for your help.
Petr
3 Likes
Thanks for the updates, I encountered the same error in Katalon Studio 8.6.0. waitForElementNotPresent does not work well anymore. Haven’t tried it in the Runtime yet.
I have extended my tool that can compare 2 versions of Katalon Studio’s jar.
My tool can indentify *.java & *.groovy files that have any difference in 2 versions,
and the tool generates the unified-diff format texts of all those different files.
The followins is the zip of the generated files: the diff of v8.4.1 and v8.6.0.
KatalonStudio_versions_diff-8.4.1-8.6.0.zip (11.0 KB), which contains the following files archived:
$ tree build/versionsDiff/
build/versionsDiff/
├── 8.4.1-8.6.0.json
└── diff
└── 8.4.1_8.6.0
└── com
└── kms
└── katalon
└── core
└── webui
├── common
│ ├── CssLocatorBuilder.java
│ └── WebUiCommonHelper.java
├── constants
│ └── StringConstants.java
├── driver
│ └── DriverFactory.java
├── keyword
│ └── builtin
│ ├── VerifyElementNotPresentKeyword.groovy
│ └── WaitForElementNotPresentKeyword.groovy
└── util
└── WebDriverPropertyUtil.java
Once the next version 8.6.1 is released, I would be able to make new diff information just easily.
1 Like
Hi all,
Just to update that our new version of Katalon Studio 8.6.5 has solved the problem. Please find more details here
2 Likes
Hi, after further tests, I can confirm that the issue is still there, even on v8.6.5 …
This thread is getting (has gotten) way, way out of hand. It’s a categorical waste of time and energy. WebUI et al are a moving target yet the DOM is not. Talk about barking up the wrong tree.
All you need is one line of JavaScript to check the DOM, wrapped in a Groovy loop.
JavaScript and the DOM APIs are tested by millions (if not billions) of people every minute of every day. Why place your faith in anything else(?).
Thank you @Russ_Thomas , but for common human (not devs) people, what would be this unique line of JavaScript ?
It’s hardly unique. There would be no point sharing code with non-developers. And besides, simple DOM API code wrapped in Groovy loops, written by me and others, has been shared many times. Try searching.
Tried to find, without success… 
I have examined if the problem which @petr.brezina pointed out in the original post has been fixed at v8.6.5 or not. See this report for my examination. I would conclude that the problem was really fixed at v8.6.5.
I doubt it.
Please prove yourself with evidences.
1 Like
Thanks a lot @kazurayam for your very useful report.
As it happened, the deployment of 8.6.5 docker image docker was unsuccessful and we were still working with v8.6.0, without realizing it!
I’m really sorry to have wasted your time.
Well, now we have a problem with FailureHandling but nothing to do with the timeout… 
OK. Nice to hear you have got a resolution.
I enjoyed programming in JavaScript to create a web page with a coundown clock as test fixture to test the waitForElementNotPresent keyword.