I tried to reproduce your issue on my side usig the alert.html you shared. Yes, I could.
I executed thiis:
import org.openqa.selenium.By
import org.openqa.selenium.WebDriver
import org.openqa.selenium.WebElement
import com.kms.katalon.core.model.FailureHandling as FailureHandling
import com.kms.katalon.core.webui.driver.DriverFactory
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI
WebUI.openBrowser("")
WebUI.navigateToUrl("http://localhost/alert.html") // I have a HTTP Server at http://localhost which makes the katalon project accessible as a web site. It does nothing special.
WebDriver wd = DriverFactory.getWebDriver();
WebElement elementOpen = wd.findElement(By.xpath("/html/body/button"));
elementOpen.click()
boolean present1 = WebUI.verifyAlertPresent(5, FailureHandling.STOP_ON_FAILURE)
// this line passed; it meas an Aleart is there.
println("present1 :" + present1)
WebUI.delay(3)
// we will check if the Aler is still there...
boolean present2 = WebUI.verifyAlertPresent(1, FailureHandling.CONTINUE_ON_FAILURE)
// Chrome+FF+Edge; this line failed; it means no Alert is there.
// Safari; thiis line passed; it means an Alert is thre. Safari seems to be a bit loose.
println("present2? :" + present2)
WebUI.closeBrowser()
on Chrome, Edge Chromium, FireFox, the 2nd WebUI.verifyAlertPresent() failed because the Alert has already disappeared automatically.
Interesting enough, on Safari, the 2nd WebUI.verifyAleartPresent() passed. I could see the Alert dialog stayed displayed on the screen.
So I guess that the newer version of security-conscious browsers (Chrome, Edge, FireFox) intentionally automatically closes Alert dialogs when a browser is controlled by software automation
like Selenium. I tried to search on Google for relevant articles on this issue, but I couldn’t find any.
I guess, Safari is outdated. Safari seems to be less security-conscious.
@Matthew_Loo
You may want to use Safari for this test. Safari seems to be your sole friend. But even Safari may change in future.
To help protect your account, Google doesn’t let you sign in from some browsers. Google might stop sign-ins from browsers that:
…
Are being controlled through software automation rather than a human
This is a proof that Chrome behaves specially when it is controlled by selenium.
I guess browsers may do something special for Alert. Alert dialog could be risky because malicious software may use Alerts to invade your peaceful life.
That’s not a very satisfactory answer, as you pointed out it’s only a matter of time before Safari starts acting the same way. The application I’m testing relays on alerts to confirm deletions, changes and saves. so you can imagine how redundant all my test cases and test suites have become. This must be happening to other tester out there, I’m surprised there isn’t a bigger commotion about this.
Also changing the way alerts are implemented , because my automation is broken would not fly with the development team. There’s time and cost to do this, especially when it works fine under normal conditions. There are much higher priorities, this would rank very lower or not at all.
If my guess — Chrome, Edge, FF does not allow automation software to test alerts, which would indicate the foreseeable direction of browser technology — is right, I think you should at least report to the development managers. You should tell them: “our application is not testable by Selenium at all due to javascript alert()!”
IMHO, they should not use JavaScript alert() for productional use cases.
There are alternatives how to implement alert dialog. For example,
The following works for me:
KSE 8.2.0
Windows 10 Enterprise (64-bit)
Chrome: 97.0.4692.71 (Official Build) (64-bit)
import static com.kms.katalon.core.testobject.ObjectRepository.findTestObject
import com.kms.katalon.core.model.FailureHandling as FailureHandling
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI
WebUI.openBrowser('http://demo.automationtesting.in/Alerts.html')
//Record the AlertBtn object or
//Create a manual AlertBtn object with XPath = //button[@onclick='alertbox()']
WebUI.waitForElementVisible(findTestObject('0.1 AlertChecks/AlertBtn'), 30, FailureHandling.OPTIONAL)
WebUI.click(findTestObject('0.1 AlertChecks/AlertBtn'), FailureHandling.OPTIONAL)
if (WebUI.verifyAlertPresent(30)) {
println('Alert is present')
}
I tried your code with KS v8.2.0 + Chrome 97.0.4692.71 on macOS 12.1. The Alert dialog disappeared instantly, and after 30 seconds the test case failed.
With Firefox 96.0.1 also failed.
With Safari 15.2 passed. I expected it to pass as reported previously.
Sadly the desired Capabilities solution did not work for me.
However, I did notice an interesting quirk, which I managed to take advantage of. In this situation I’m automating the keypress of the delete button on my form. The alert flashed on and then off. If I now manually pressed the delete button the Alert appeared and stayed. So with that in mind, I wrote this, which works. it’s not pretty, please let me know if there’s a nicer way.
Your code may be suffering from “compensating errors” and, luckily for you, you coded it in such a way (try-catch) that the final compensation “works”. The problem with compensating errors is this:
When you fix one of the errors, the other error then appears.
My guess is, you don’t need the try-catch. You merely need to…
WebUI.click(...)
WebUI.waitForAlert(5) // that's a LONG time!
WebUI.acceptAlert()
Of course, you may need to tinker with the timeouts, but I’d be surprised if you truly need anything else. And frankly, I couldn’t live with a try-catch like that – it’s just waiting to bite me.
But even Safari may change in future.
