Selenium Click Command: Syntax, Examples, and Troubleshooting (2026)

Selenium Click Command: Syntax, Examples, and Troubleshooting

Huyen Nguyen

Technical Writer, Katalon Updated on

Learn with AI

click() looks like the simplest method in Selenium's API, and most of the time it is. The complexity shows up when it silently fails: the element exists, your locator is correct, and the click still does not register, or worse, it lands on the wrong thing entirely.

This guide covers the click() method itself, when to reach for the Actions class instead, and the handful of failure patterns, ElementClickInterceptedException, overlays, hidden elements, that account for nearly every "the click did not work" report.

Here is what we will cover:

What click() actually does, and when it is enough on its own
A complete click test, from navigation to assertion, not an isolated snippet
click() versus Actions.click(), contextClick(), doubleClick(), and a JavaScript executor click, side by side
Where to go for double-click and right-click specifics
Troubleshooting a click that will not register: interception, overlays, hidden elements, and scrolling

THE SHORT ANSWER

How to click in Selenium, at a glance:
• click() is the default. It works on any element that is visible, enabled, and not obstructed.
• Use Actions.click() when you need to chain a hover or key press together with the click.
• contextClick() simulates a right-click and doubleClick() simulates a double-click, both through the Actions class.
• A JavaScript executor click bypasses visibility checks entirely. Treat it as a last resort, not a default.
• Most "the click does not work" failures are ElementClickInterceptedException from an overlay, not a broken locator.

The comparison table and troubleshooting section below cover exactly when each approach is the right call.

What click() actually does

The Selenium click command, click(), is a method on the WebElement interface. Call it on a located element and Selenium simulates a real user click: a left mouse click, fired only if the element is visible, enabled, and not covered by anything else at that point on the page. You will find it in almost every Selenium test script; whether you are validating a navigation flow or triggering a JavaScript event, click() is what makes that interaction happen.

The rule of thumb: if a real user can click it, you can test it with click(). The cases where that is not enough, an intercepted click, a hidden element, a race against the page still loading, are what the rest of this guide is about. For the fundamentals of Selenium itself, our Selenium testing tutorial covers WebDriver, Grid, and IDE from the ground up.

A complete click test, from navigation to assertion

Most click examples stop at the click itself, which hides the part that actually matters: confirming the click did something. Here is a full example, navigating to a page, waiting for a real element, clicking it, and asserting the result.

Java

import java.time.Duration;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

WebDriver driver = new ChromeDriver();
driver.get("https://katalon.com");

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement trialBtn = wait.until(
    ExpectedConditions.elementToBeClickable(By.linkText("Start free trial"))
);
trialBtn.click();

wait.until(ExpectedConditions.urlContains("open-true-platform"));
assert driver.getCurrentUrl().contains("open-true-platform") : "Click did not navigate to the signup flow";

driver.quit();

Python

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Chrome()
driver.get("https://katalon.com")

wait = WebDriverWait(driver, timeout=10)
trial_btn = wait.until(EC.element_to_be_clickable((By.LINK_TEXT, "Start free trial")))
trial_btn.click()

wait.until(EC.url_contains("open-true-platform"))
assert "open-true-platform" in driver.current_url, "Click did not navigate to the signup flow"

driver.quit()

Notice the elementToBeClickable wait before the click, not just a presence check. That single choice is what separates a stable click from a flaky one; our guide to explicit wait in Selenium covers why.

One caveat on the Java version: the built-in assert keyword does nothing unless the JVM runs with the -ea flag, silently passing even on a real failure if that flag is missing. It works for a quick illustration like this one, but a real test suite should use JUnit's or TestNG's own assertion methods instead, which do not depend on a launch flag to actually run.

click() vs Actions.click() vs contextClick() vs doubleClick() vs a JavaScript executor

Selenium gives you five ways to trigger something that looks like a click. They are not interchangeable, and reaching for the wrong one either misses the interaction you meant to test or hides a real bug behind a passing test.

	Selenium Click Methods Five ways to trigger a click, and when each one is the right call.
click()	The default method on any WebElement. Simulates a real left-click if the element is visible, enabled, and not obscured. Start here; reach for the alternatives below only when it fails or the interaction itself needs to be non-standard.
Actions.click()	The same left-click, built through the Actions class instead of called directly on the element. Useful when you need to chain it with another interaction, a hover first, or a key held down during the click, or when a plain click() gets intercepted but a synthesized one succeeds.
contextClick()	Simulates a right-click, opening whatever context menu your application renders. Only useful if the app implements its own custom menu; the browser's native right-click menu is outside what Selenium can inspect or interact with.
doubleClick()	Simulates two rapid clicks. Needed for UI patterns that specifically listen for a double-click event, inline text editing, file-manager-style icons, a single click() will not trigger that behavior.
JavaScript executor	Runs arguments[0].click() directly in the browser, bypassing Selenium's visibility and interactability checks entirely. It will "click" elements a real user could not reach, which can mask genuine bugs. Use it as a last resort for a persistent ElementClickInterceptedException, never as a default.

Double-clicking and right-clicking in Selenium

contextClick() and doubleClick() both deserve more depth than a quick mention here. Our dedicated guide to double-clicking and right-clicking in Selenium covers full Java and Python examples for both, plus the failure modes specific to each.

Troubleshooting a click that will not register

The syntax is rarely the problem. A click that "does not work" is almost always one of these.

ElementClickInterceptedException. Selenium found the element and computed where to click, but a different element sits on top of that point, a cookie banner, a sticky header, a modal, so the click hits the overlay instead. Scroll the target into a part of the page the overlay does not cover, then retry the wait and click:

Java

import java.time.Duration;
import org.openqa.selenium.By;
import org.openqa.selenium.ElementClickInterceptedException;
import org.openqa.selenium.JavascriptExecutor;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));

try {
    driver.findElement(By.id("checkout-button")).click();
} catch (ElementClickInterceptedException e) {
    WebElement checkoutBtn = driver.findElement(By.id("checkout-button"));
    ((JavascriptExecutor) driver).executeScript("arguments[0].scrollIntoView({block: 'center'});", checkoutBtn);
    wait.until(ExpectedConditions.elementToBeClickable(checkoutBtn)).click();
}

Python

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.common.exceptions import ElementClickInterceptedException

wait = WebDriverWait(driver, timeout=10)

try:
    driver.find_element(By.ID, "checkout-button").click()
except ElementClickInterceptedException:
    checkout_btn = driver.find_element(By.ID, "checkout-button")
    driver.execute_script("arguments[0].scrollIntoView({block: 'center'});", checkout_btn)
    wait.until(EC.element_to_be_clickable((By.ID, "checkout-button"))).click()

Waits and timing. The element is in the DOM before it is actually interactable, a classic race condition. Wait for elementToBeClickable, not just presence; see the full breakdown in our explicit wait guide.

Hidden elements. An element with zero size or display: none cannot receive a real click, Selenium will correctly refuse it. A JavaScript executor click can "succeed" against a hidden element anyway, which is one more reason not to default to it: a test that passes against an element no user could ever see or click is worse than a test that fails honestly.

Scrolling. An element outside the current viewport will not register a standard click. Actions.moveToElement() scrolls automatically before interacting; a manual scrollIntoView({block: 'center'}) via the JavaScript executor works too, and is safer than the default scrollIntoView(true), which can scroll the target behind a sticky header.

When not to reach for a JavaScript click. It bypasses the same visibility and interactability checks that make Selenium's click meaningful in the first place. Defaulting to it hides real problems: if an overlay blocks a real customer from clicking a button, that is a product bug, not a test problem, and a JS click will paper over it with a green checkmark. Reserve it for scrolling elements into view, or as a last-resort workaround for a confirmed, non-blocking test-environment artifact, not as the default way to click.

How Katalon simplifies Selenium clicks

Katalon builds on Selenium and Appium, adding a keyword-driven layer on top of the click methods above. Instead of writing raw Selenium code, a single keyword like WebUI.click(findTestObject ('ObjectName')) handles the click, and Katalon automatically retries it when an overlay briefly intercepts the target, the same failure the troubleshooting section above walks through manually.

The same keyword-driven approach covers every click type in this guide, not just the standard click. WebUI.doubleClick() WebUI.doubleClick() and WebUI.rightClick() mirror Actions.doubleClick() and contextClick(), without the extra chaining, and inherit the same retry logic. See the WebUI Double-click docs and WebUI Right-click docs for the full keyword reference, or the double-clicking and right-clicking in Selenium guide above for side-by-side examples against the Actions class.

A few reasons teams already using Selenium adopt Katalon for this specific problem:

Built-in retry logic: Katalon re-attempts a click that gets intercepted or hits a stale element, without you writing the try/catch pattern shown above by hand.
Object Repository: locators live in one place and get reused across test cases, instead of being duplicated as string literals in every script.
AI-assisted self-healing: when a UI change breaks a locator, Katalon can adapt rather than fail the whole suite.
Cross-browser and mobile execution: the same click logic runs across Chrome, Firefox, Safari, Edge, Android, and iOS.

To go deeper, the free Using Built-in Keywords in Katalon course covers test objects and reusable keywords, and the Katalon WebUI.click() docs explain the retry behavior in full.

📝 Tired of hand-writing retry logic for every intercepted click? Start a free trial and see Katalon's built-in click retry and self-healing locators handle it automatically.

Explain

FAQs

What does the Selenium click command do?

The Selenium click command, click(), is a method on the WebElement interface. Calling it simulates a real user's left-click, but only if the element is visible, enabled, and not covered by anything else at that point on the page.

Why does a Selenium click sometimes fail?

Most click failures throw ElementClickInterceptedException. Selenium found the element and computed where to click, but a different element, a cookie banner, a sticky header, or a modal, sits on top of that point, so the click hits the overlay instead. Scrolling the target into an uncovered part of the page and retrying the wait usually fixes it.

What's the difference between click(), Actions.click(), contextClick(), doubleClick(), and a JavaScript executor click?

click() is the default and should be your first choice. Actions.click() is the same left-click, built through the Actions class so it can be chained with a hover or key press. contextClick() simulates a right-click and doubleClick() simulates a double-click, both also through the Actions class. A JavaScript executor click bypasses Selenium's visibility and interactability checks entirely, and should be a last resort, not a default.

Why shouldn't I just use a JavaScript executor to click elements?

Because it bypasses the same visibility and interactability checks that make a Selenium click meaningful in the first place. If an overlay is genuinely blocking a real user from clicking a button, that is a product bug, and a JavaScript click will mask it with a passing test instead of surfacing it.

How do you perform a double-click or right-click in Selenium?

Both go through the Actions class: doubleClick() for a double-click, contextClick() for a right-click. Our dedicated guide to double-clicking and right-clicking in Selenium covers full Java and Python examples for both.

How does Katalon improve the Selenium clicking process?

Katalon simplifies click automation with keyword-driven actions like WebUI.click(), an Object Repository for reusable locators, automatic retries when an overlay intercepts a click, cross-browser and mobile execution, and built-in reporting.

Huyen Nguyen

Technical Writer, Katalon

Huyen Nguyen is an experienced technical writer in the software testing industry. With strong technical expertise and a deep understanding of Katalon products, she creates clear, practical guides that support testers at every skill level.