The element is not clickable

[Preeti_Diwakar]

Even though the element is clickable, it is giving an error that element is not clickable at that time.

[Russ_Thomas]

Did you check it’s visible first?

https://docs.katalon.com/display/KD/[WebUI]+Wait+For+Element+Visible

[Matthew_Miyares]

I am getting this error as well. I’m running Katalon Studio 5.4.2 on Windows 7 testing on Chrome 66. The object I am trying to target is an “I Agree” button to click through a warning page. I used both WebRecorder and Web Spy to capture the object, but in both cases running the script would not actually click through.

The exact error returned is here:

Test Cases/Automated Login FAILED because (of) Unable to click on object ‘Object Repository/Page_Welcome to HCQIS CAADS/a_ I Agree’ (Root cause: org.openqa.selenium.WebDriverException: unknown error: Element … is not clickable at point (88, 520). Other element would receive the click:

…

(Session info: chrome=66.0.3359.181)

(Driver info: chromedriver=2.35.528161 (5b82f2d2aae0ca24b877009200ced9065a772e73),platform=Windows NT 6.1.7601 SP1 x86_64) (WARNING: The server did not provide any stacktrace information)

Command duration or timeout: 0 milliseconds

Build info: version: ‘3.7.1’, revision: ‘8a0099a’, time: ‘2017-11-06T21:07:36.161Z’

System info: host: ‘VDIBASE-037’, ip: ‘172.23.236.152’, os.name: ‘Windows 7’, os.arch: ‘amd64’, os.version: ‘6.1’, java.version: ‘1.8.0_102’

Driver info: com.kms.katalon.selenium.driver.CChromeDriver

Capabilities {acceptInsecureCerts: false, acceptSslCerts: false, applicationCacheEnabled: false, browserConnectionEnabled: false, browserName: chrome, chrome: {chromedriverVersion: 2.35.528161 (5b82f2d2aae0ca…, userDataDir: C:\Users\gd0239\AppData\Loc…}, cssSelectorsEnabled: true, databaseEnabled: false, handlesAlerts: true, hasTouchScreen: false, javascriptEnabled: true, locationContextEnabled: true, mobileEmulationEnabled: false, nativeEvents: true, networkConnectionEnabled: false, pageLoadStrategy: normal, platform: XP, platformName: XP, rotatable: false, setWindowRect: true, takesHeapSnapshot: true, takesScreenshot: true, unexpectedAlertBehaviour: , unhandledPromptBehavior: , version: 66.0.3359.181, webStorageEnabled: true}

Session ID: 34691c867e500b75e8940f57b3161100)

[Russ_Thomas]

The error is telling you there is something in the way of your button – it’s a DIV element with class “pageFooterDjj”

[Matthew_Miyares]

OK, I’ll get back to the web designer about that.

[Mate_Mrse]

You could use [WebUI] Wait For Element Not Visible on the

…

element.
If that doesn’t work, try using JavaScript:
http://forum.katalon.com/discussion/1736/unable-to-click-on-object-other-element-would-receive-click

[Zarashima]

You can refer to solution described here: https://docs.katalon.com/display/KD/Troubleshooting+common+issues+related+to+interacting+with+an+element

[Matthew_Miyares]

Just as an update, the particular issue I was facing was that the footer on the webpage was at a higher “layer” than the other elements, meaning that any clicks to elements underneath wouldn’t be received. All that was needed to clear up my own issue was adding a “Scroll to Element” command to get the footer out of the way.

[Russ_Thomas]

…is not clickable at point (88, 520)

All that was needed to clear up my own issue was adding a “Scroll to
Element” command to get the footer out of the way.

Let me take a wild guess - you recorded your test and expected it to work. Right?

It’s far better to manually add your objects to the system if you want to avoid time-wasting endeavors like this (better still, build your own objects, “live” in memory during your test).

[Curtis_BRODERICK]

Let me take a wild guess - you recorded your test and expected it to work. Right?

Ohh, that is too funny. Thanks! You started my Friday off rather nicely. Thanks @Matthew_Miyares for the fix suggestion, but even with scroll to “element” (which fixed a previous text field – and now I want to save the form), I still get

Element <input type="button" onclick="return false;" id="scum_savret" class="btn undefined btn-default" value="Save and return"> is not clickable at point (181, 472). Other element would receive the click: <div class="yui3-widget-mask" style="position: fixed; width: 100%; height: 100%; top: 0px; left: 0px; z-index: 1000;">

My script said:
WebUI.scrollToElement(findTestObject(‘Pages (Pond Scum Tests)/scum button save and return’), 0)
WebUI.click(findTestObject(‘Pages (Pond Scum Tests)/scum button save and return’))

[Brandon_Hein]

Have you considered using JavaScript to click on elements instead of the WebUI API (which uses Selenium commands in the background)?

We have apps that have overlays, things rendering on top of each other periodically, modal dialogs, etc, and often you’ll get much more consistent and desirable behavior using Javascript, jQuery, etc, to do the majority of the work:

import static com.kms.katalon.core.testobject.ObjectRepository.findTestObject

import org.openqa.selenium.JavascriptExecutor
import org.openqa.selenium.WebDriver
import org.openqa.selenium.WebElement

import com.kms.katalon.core.webui.common.WebUiCommonHelper
import com.kms.katalon.core.webui.driver.DriverFactory

// Turn your TestObject into a WebElement...
WebElement element = WebUiCommonHelper.findWebElement(findTestObject("my/test/object"), 30);

// Get the current driver from Katalon and convert to a JavascriptExecutor...
WebDriver driver = DriverFactory.getWebDriver();
JavascriptExecutor jsExecutor = (JavascriptExecutor)driver;

// Click your WebElement using JavaScript...
jsExecutor.executeScript("arguments[0].click();", element);

If you find that this kind of thing works for you, consider creating a Custom Keyword that acts as a utility method, then you can pass any objects that you want to click. Also, this approach isn’t limited to clicking on elements, we also use similar methods to set dropdowns, send keys to text fields, etc.

Hope this helps!

[Russ_Thomas]

You can shorten that code @Brandon_Hein by using https://docs.katalon.com/katalon-studio/docs/webui-execute-javascript.html.

And if you bypass TestObjects you can empty out your Object Repository and all the maintenance that goes with it too. Use the same philosophy you mentioned, but create a method that takes a CSS selector and shoots off the click (or whatever)…

static void clickUsingJS(String selector) {
  WebUI.executeJavaScript('document.querySelector("' + selector + '").click()', null)
}

[Brandon_Hein]

@Russ_Thomas Nice, I didn’t realize that the WebUI class had that wrapper method. But I would still suggest using the Object Repository to manage locators/selectors. In our case, we have several layers, one of which is a Page Object layer, which calls the repository for the TestObject, converts to WebElement, passes to the utility methods to perform the action, and handles any wait conditions after the action is performed. It’s a matter of preference, but I would prefer handling TestObjects rather than digging through a class to find a given selector. In that case it would look like:

static void clickUsingJS(WebElement element) {
  WebUI.executeJavaScript("arguments[0].click();", element);
}

[Russ_Thomas]

No problem, Brandon, as you say, it’s a matter of preference(s).

Me, I’d rather fly direct from New York to London. An excursion to Tokyo “midway”, to me, makes no sense. Test Objects (in this, I admit, poor analogy) are Tokyo. They’re a contrivance the efficacy of which eludes me. They “pack up” and “wrap” HTML elements. They need unpacking once they reach code that communicates with the browser. APIs are required to unwrap them to convert to another wrapper “WebElement”…

Nope. Just don’t get it. Sorry.

Browsers use CSS as selectors. CSS is optimized beyond belief (and certainly beyond my humble abilities to achieve). I’ll stick with them and eshew anything that prevents me from using them in as direct a manner as possible.

Anyway, I’ve harped on about this enough in these forums. Time I just shut the hell up

Oh… almost forgot. You can of course make your own TestObjects “live” in memory (and still dump the OR) if you want the best of both worlds. Search on makeTO.

[Brandon_Hein]

Calling them contrived is a bit unfair. While they are indeed less direct than a simple CSS selector passed as a string, I would argue that their convenience and versatility far outweigh the extra baggage. Consider the following:

1.) Most Katalon users will be more familiar/comfortable with the use of TestObjects, as all the tutorials and documentation will encourage and detail their use.
2.) While CSS as a selection strategy is indeed optimized, it’s by no means the most readable nor does it provide the most power in terms of complex location strategies. XPath probably takes the cake on that one.
3.) The utility method you’ve provided betrays the single responsibility principle, as it’s both locating and manipulating the element. In my case, the TestObject (and by extension, the underlying WebElement), having already been located, can be passed around to other methods to do a lot of other cool stuff like getting attribute values, finding other elements relative to it, etc.

Thanks as always for the informed discussion, it’s always enlightening to see how others approach these things.

[Russ_Thomas]

Calling them contrived is a bit unfair. While they are indeed less direct than a simple CSS selector passed as a string, I would argue that their convenience and versatility far outweigh the extra baggage. Consider the following:

1.) Most Katalon users will be more familiar/comfortable with the use of TestObjects, as all the tutorials and documentation will encourage and detail their use.

Oh, agreed. “We are where we are”. My suspicion is though, that it’s more the Recorder tool that drove their need/requitement. Either way, it’s the effect of the cause (whatever the actual cause).

2.) While CSS as a selection strategy is indeed optimized, it’s by no means the most readable nor does it provide the most power in terms of complex location strategies. XPath probably takes the cake on that one.

Agreed. XPath certainly wins if backtracking (parent/ancestor selection) is required.

3.) The utility method you’ve provided betrays the single responsibility principle, as it’s both locating and manipulating the element. In my case, the TestObject (and by extension, the underlying WebElement), having already been located, can be passed around to other methods to do a lot of other cool stuff like getting attribute values, finding other elements relative to it, etc.

That’s fair. Not sure I see/feel the need to worry about design philosophy to that level in automated testing (I’m open to being convinced though).

Thanks as always for the informed discussion, it’s always enlightening to see how others approach these things.

Sure! I’m wrong way more often than I’m right

[Brandon_Hein]

Not sure I see/feel the need to worry about design philosophy to that level in automated testing (I’m open to being convinced though).

I believe this depends on the complexity of the application(s) you are testing. In our case, we have several clients that all use an implementation of an application that has a shared code base, but that also has significant differences from other client implementations. In this kind of environment, OOP design principles are paramount, especially with a small team of testers to write/maintain a large script base.

Admittedly, the amount of abstraction may be overkill for a lot of people, but it never hurts to approach an automation project just like you would any development project.

[Curtis_BRODERICK]

Hi guys,
Thanks for the informative and extremely polite exchange to help understand how to get at those elements that have other element laid over them. “Where I am at” as a beginner is keeping an object library (I use the spy web and then manually adjust the Xpath as needed) to keep myself organized. Trying to understand a bit @Brandon_Hein code I have the following question (sorry, never programmed in java):

The two lines of // Get the current driver from Katalon and convert to a JavascriptExecutor… just need to be executed once (place that right after the imports of my script) and then whenever I have a web element that gives the old "Web element not clickable at point… " I can 1. Turn my testobject into a web element and then 2. click the web element using javascript ? That the idea? Seems to have worked for the first element but not the second.

[Russ_Thomas]

No, Curtis. Brandon was giving you a self contained, working demo. As he goes on to say…

If you find that this kind of thing works for you, consider creating a Custom Keyword that acts as a utility method, then you can pass any objects that you want to click.

So the general idea is, create a method (i.e. a Keyword in current Katalon parlance), call it something like “jsClicker” and then you can wrap that code up into a simple/single utility method you can call from any test case. He also goes on to suggest you could extend the idea to other scenarios, like for example, retrieving values, checking attributes etc, all using JS.

Personally, I don’t bother using the @Keyword decorator. I just make my util methods static and import the lib statically everywhere I need it.

static void jsClicker(whatever) {
  // do js stuff
}

If you haven’t done so already, read this:

https://docs.katalon.com/katalon-studio/docs/sample-custom-keywords.html

[Brandon_Hein]

@Curtis_BRODERICK

Exactly as Russ and I have said, if it’s something that you want to use across multiple scripts (which you almost certainly will if it worked for you already), you will want to encapsulate this into a method. Russ has linked you a demo on generally how to create/work with Custom Keywords, but I can also give you a brief demo and some code to get you started:

1.) In your Tests Explorer, right click on Keywords, then click on New > Keyword

2.) You’ll be prompted with a dialog. For now, just call the Package “util” and the Class Name “Util” (this follows Java convention):

Feel free to reorganize/rename things later of course.

3.) Since you said you are using the Object Repository, I will assume that you will be passing TestObjects to the utility method. If that’s the case, go ahead and copy over all of the auto-generated code in your Util class with the following (Updated this to match the solution from below that seems to work better):

package util

import org.openqa.selenium.JavascriptExecutor
import org.openqa.selenium.WebDriver
import org.openqa.selenium.WebElement

import com.kms.katalon.core.testobject.TestObject
import com.kms.katalon.core.webui.common.WebUiCommonHelper
import com.kms.katalon.core.webui.driver.DriverFactory

public class Util {

	public static void jsClick(final TestObject testObject) {
		WebElement element = WebUiCommonHelper.findWebElement(testObject, 30);
		WebDriver driver = DriverFactory.getWebDriver();
		JavascriptExecutor jsExecutor = (JavascriptExecutor)driver;
		jsExecutor.executeScript("arguments[0].click();", element);
	}
}

4.) You can then call this method from ANY Test Case that you want just by importing the Util class, and calling the method:

import com.kms.katalon.core.testobject.ObjectRepository
import com.kms.katalon.core.testobject.TestObject as TestObject

// This is the import statement for the "Util" Custom Keyword we've created:
import util.Util

TestObject myTestObject = ObjectRepository.findTestObject("path/to/my/object");
Util.jsClick(myTestObject);

If you choose not to wrap this up into a method, you will be forced to type out this code yourself anytime you want to use JS to click something, which obviously isn’t great.

Hope this helps!