Well, hard to choose the right solution right now, but I think users not aware about smart wait specific, are just using it as it is.
So, keeping the global setting enabled by default but enabling the users willing to disable it locally on specific needs no matter of the global setting will be the path with minimum breakage.
the main issue seems to be caused by this duplicated logic (global vs local) and how it is handled.
I will think a bit more on this, should be a decent solution …
LE: there mai be two main cases, i guess:
globaly enabled but the user needs to temporary disable
globaly disabled but the user needs to temporary enable
I think an if / else is needed to handle them properly.
If i understand the doc about Optional right, it means if the LOCAL_SMART is unset (null) this code returns true. which is odd.
removing the orElse method, the if can be modified a bit.
check first the localSmart with isPresent so if this is not null (has value) should preffer the local value, otherwise the global one
A bit more changes may be needed for things to work properly.
Keeping the cast as boolean (but removing orElse) will return false. Easy to do but …
This is not what I wanted to see, since I may like to check if this is actually set or unset (user choice).
Attempting to use isPresent() on a boolean will throw an exception, obvioulsy.
So, I made a sample code like this to see how we can play better.
The main trick is at:
I think, this should be backward compatible. Can be improved a bit i guess, but I will let it to Katalon team to decide.
Until this is addressed, the only option for the user is to manually override GLOBAL_SMART_WAIT_MODE per the @kazurayam example
The right logic when this has been implemented, as repeated few times by @Russ_Thomas, should have been:
opt in for smart wait, no matter globally or locally (default disabled)
… however, now is a bit late
The current logic is:
user can enable or disable smart wait by code only if is globally enabled
… which is meh IMHO (i was tempted to say ‘childish’ but I may be sued again)
The improved logic can be (with backward compatibility in mind):
choice by code should be respected, global settings should be followed only if there is no code choice
Having all this sumarrized, for the current topic the @kazurayam workaround has to be marked as solution, the remaining are just details on what katalon developers may have to do:
Thank you all for such an interesting discussion and lots of effort here. I have raised the issue of this Smart Wait for my team and hope to update with you soon if any further thing.
Sorry for not able to read the whole thread and late response. Have a good day~
I have some problem when trying to connect using Windows 11 here are the errors
java.util.concurrent.ExecutionException: org.openqa.selenium.WebDriverException: Connection refused: no further information
Build info: version: '3.141.59', revision: 'e82be7d358', time: '2018-11-14T08:25:53'
System info: host: 'SYLVIA-ASTRIDA', ip: '192.168.10.184', os.name: 'Windows 11', os.arch: 'amd64', os.version: '10.0', java.version: '17.0.7'
Driver info: driver.version: WindowsDriver
at com.kms.katalon.composer.components.impl.dialogs.ProgressMonitorDialogWithThread.runAndWait(ProgressMonitorDialogWithThread.java:49)
at com.kms.katalon.composer.windows.dialog.WindowsAppComposite$5.run(WindowsAppComposite.java:240)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)
Caused by: org.openqa.selenium.WebDriverException: Connection refused: no further information
Build info: version: '3.141.59', revision: 'e82be7d358', time: '2018-11-14T08:25:53'
System info: host: 'SYLVIA-ASTRIDA', ip: '192.168.10.184', os.name: 'Windows 11', os.arch: 'amd64', os.version: '10.0', java.version: '17.0.7'
Driver info: driver.version: WindowsDriver
at io.appium.java_client.remote.AppiumCommandExecutor.lambda$5(AppiumCommandExecutor.java:251)
at io.appium.java_client.remote.AppiumCommandExecutor.execute(AppiumCommandExecutor.java:250)
at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:552)
at io.appium.java_client.DefaultGenericMobileDriver.execute(DefaultGenericMobileDriver.java:42)
at io.appium.java_client.AppiumDriver.execute(AppiumDriver.java:1)
at io.appium.java_client.windows.WindowsDriver.execute(WindowsDriver.java:1)
at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:213)
at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:131)
at io.appium.java_client.DefaultGenericMobileDriver.<init>(DefaultGenericMobileDriver.java:38)
at io.appium.java_client.AppiumDriver.<init>(AppiumDriver.java:84)
at io.appium.java_client.windows.WindowsDriver.<init>(WindowsDriver.java:38)
at com.kms.katalon.core.windows.driver.WindowsDriverFactory.newWindowsDriver(WindowsDriverFactory.java:194)
at com.kms.katalon.core.windows.driver.WindowsDriverFactory.startApplication(WindowsDriverFactory.java:112)
at com.kms.katalon.composer.windows.spy.WindowsInspectorController.startApplication(WindowsInspectorController.java:150)
at com.kms.katalon.composer.windows.dialog.WindowsAppComposite$5$1.call(WindowsAppComposite.java:243)
at com.kms.katalon.composer.components.impl.dialogs.ProgressMonitorDialogWithThread.startThreadAndWait(ProgressMonitorDialogWithThread.java:36)
at com.kms.katalon.composer.components.impl.dialogs.ProgressMonitorDialogWithThread.runAndWait(ProgressMonitorDialogWithThread.java:48)
... 2 more
Caused by: java.net.ConnectException: Connection refused: no further information
at okhttp3.internal.platform.Platform.connectSocket(Platform.java:129)
at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.java:245)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:165)
at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:257)
at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:135)
at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:114)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:126)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:200)
at okhttp3.RealCall.execute(RealCall.java:77)
at org.openqa.selenium.remote.internal.OkHttpClient.execute(OkHttpClient.java:103)
at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:105)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at io.appium.java_client.remote.AppiumCommandExecutor$1.createSession(AppiumCommandExecutor.java:186)
at io.appium.java_client.remote.AppiumCommandExecutor.createSession(AppiumCommandExecutor.java:217)
at io.appium.java_client.remote.AppiumCommandExecutor.execute(AppiumCommandExecutor.java:239)
... 17 more