WebUI.acceptAlert() is not working in Version 8.6.0

No alert found (Root cause: com.kms.katalon.core.exception.StepFailedException: No alert found
at com.kms.katalon.core.webui.keyword.internal.WebUIKeywordMain.stepFailed(WebUIKeywordMain.groovy:64)
at com.kms.katalon.core.webui.keyword.builtin.AcceptAlertKeyword$_acceptAlert_closure1.doCall(AcceptAlertKeyword.groovy:78)

Hi @Sandip_Patel

Really hard to determine why it could not find the alert.

Can you perhaps add a screenshot of the alert and the line of code that does the check?

Also while you are here please have a quick read through :slight_smile: :

screen_recording_1_0.srt (2.7 KB)

By looking at your logs I can see that the test case fails even before the acceptAlert(). Are you sure the alert does get displayed? Because if the alert does not display it would explain why you are getting the error ‘No alert found’

Alert is Disply and shut it within Miliseconds , and showing error logs as no alert found
This is angular Page

1 Like

The video you posted does not play. Not sure if it is in a format not supported by this forum or even if you can post videos.

It is known that the web browsers — Chrome, Edge, FF — have tightened their security and changed the design so that the browsers do not allow the automation software (Selenium, Katalon, etc) to test JavaScript Alerts any longer. The recent version of browser is designed to close the Alert window immediately when the page is driven by Selenium.


Effectively, the WebUI.acceptAlert() keyword is no use any longer.

Thank for reply
In Previous Katalon Version, its was working fine , this is old scripting code, after Updated version, showing alert not found error , you can see , also facing same error to other people as per search Forum - alert not found

1 Like

No, the Katalon version is not significant, I think.

Browsers have changed the design.

yes , may be , can we change any borwser settings or secuirty for same , can you please suggest

I don’t know, sorry.

I think that it is better to change your Application Under Test so that it does not use JavaScript alert() at all.

You can try adding to the desired capabilities settings.

Go to Project > Project Settings > Desired Capabilities > Web UI > Chrome (Headless)

Click Add

Give it a name ‘prefs’

And type Dictionary

Then click on the

Then create the following

Name = unexpectedAlertBehaviour
Type = String
Value = ignore

This should not make chrome close the alert if you are using the chrome (headless) driver, which for me is the default driver

1 Like

From a technical perspective, this is correct.
Alerts should never land in production code, it is already proven why.
(it breaks the execution loop so it has to be used more like a ‘breakpoint’ for debug … but limited)
Nor console.log (I won’t tell you why)

From the tester perpective, it may vary.

For some reasons, using the console to rise an alert still works at least for my case, manually browsing and using DevTools.

E.g. in Chrome 112.0.5615.49 those still works:


Therefore, it is a case-by-case solution.
The alert may be automatically closed because the browser detects automation is in use (we saw that before in some other topics) … workarounds may exist
(search the forum and stackoverflow about)

But, as @jmeintjesn7 this may be caused by the headless driver used, which is a different animal.

Therefore, we need more data.

@Sandip_Patel kindly review this topic:

@Sandip_Patel also mention that:

In Previous Katalon Version, its was working fine , this is old scripting code

therefore, kindly repeat your tests with some older Katalon versions (but your actual code, browser and drivers) se we can locate who is breaking what.

@Sandip_Patel Your AVI video plays fine here (after I downloaded it first).

Kaz, I don’t know where you got this information, but it’s wrong. There is nothing wrong with WebUI.acceptAlert() and Webdrivers (browsers) have always treated alerts the same as you’re witnessing – at least, in all my time testing since their earliest days.


I took a look at your code. A couple of things stood out that you should change. The lines of code following the line that triggers the alert are likely causing your problem:

Make this a mantra from now on:

Deal with the alert IMMEDIATELY after the line of code that triggers the alert.

If we take a look at your code again…

You should process the alert immediately after the click on the btn_Save element.

There is one more thing I would change: always WAIT for the alert, then accept it. Something like this:

   * Wrapper over <code>WebUI.waitForAlert</code> and <code>WebUI.acceptAlert</code>.
  void confirmAlert() {

That’s actually my production code, in use for ~5 years, at least. (Aside: I bet that WebUI.delay(1) is unnecessary).

So, to sum up, drop that method into code somewhere and call it immediately after the click on btn_Save.

I got the observation by my experiment, which I posted public previously at

I have created a GitHub repository; with it you can reproduce my findings .

You need to start a tiny HTTP server locally.

$ cd ks_AlertDialogueDisappears

$ groovy server.groovy

The server.groovy is dependent on the version of Groovy. You must have Groovy v2.4.x installed

$ groovy --version
Groovy Version: 2.4.21 JVM: 11.0.18 Vendor: Amazon.com Inc. OS: Mac OS X

Then you want to run Test Cases/testAlert while specifying type of browsers: Chrome, FF, Safari, …

Yes. My experiment also revealed that a alert dialogue is there immediately after the click on a button.

But, in a few seconds after the click, the alert dialogue is no longer there = it disappears somehow. So I guess that browser intentionally closed the alert dialogue if the page is controlled by Selenium.

I checked Chrome, Edge, FF and Safari. I found the former 3 browsers close the alert when the page is controlled by Selenium. I found that Safari does not close the alert. I suppose the Safari team doesn’t have enough number of developers.

I repeat, there’s nothing wrong with WebUI.acceptAlert() – it works. See the little method I posted.

1 Like

I agree with you.

Safari is based on Webkit which is a very old framework, poorly developped.
Only ancient apps are still using it (e.g Thunderbird email client)
And ofcourse, katalon :smiley:
Even Falkon browser which was formerly based on QTWebKit switched to QTWebEngine (which is based on a stripped down chromium) due to lack of new features to keep up with the current trends.
Chrome and Edge are both based on chromium engine, so it makes sense why behave the same.
FF i forgot what is using … but usually they keep up with what Chromium implements, it’s a race.

Anyway, chances are something like enable-automation to work, if that’s the case, to trick the browser to display them.
ref: java - Chrome is being controlled by automated test software - Stack Overflow

or a certain other capability

Found this:

so, something like unexpectedAlertBehaviour=ignore may work, as already suggested by @jmeintjesn7