Skip to content
QA Knowledge Hub

ElementClickInterceptedException in Selenium

Updated 2026-11-13 · 2 min read

A click target can be visible and enabled while another node covers its centre. Diagnose overlays and layout changes before bypassing normal interaction.

Recognise the error

The official Java API names this exception:

org.openqa.selenium.ElementClickInterceptedException

This is the documented exception identifier, not a reproduced stack trace. Driver-specific wording and diagnostic details vary. Keep the full message from your own run; no browser error was reproduced for this page. Java fragments below assume an existing Selenium 4 WebDriver driver and standard Selenium imports. They were checked against the APIs but not compiled or run here.

The target exists, but another element would receive the click. On a checkout page, a loading mask may cover the Pay button even while that button is enabled.

The WebDriver specification defines the corresponding protocol error string as:

element click intercepted

1. A loading mask or modal covers the button

Check the screenshot and the obstructing element in the driver message first. Wait for the known mask to disappear, then locate the button again.

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.invisibilityOfElementLocated(By.id("loading-mask")));
wait.until(ExpectedConditions.elementToBeClickable(By.id("pay"))).click();

For a cookie dialog, dismiss it through its visible control before clicking Pay. Do not delete the dialog with injected JavaScript; that skips the actual journey.

2. A sticky header or animation covers the click point

A button can be visible in part while its centre is covered. Try centring it, then wait for the application's documented ready state before clicking.

WebElement pay = driver.findElement(By.id("pay"));
((JavascriptExecutor) driver).executeScript(
    "arguments[0].scrollIntoView({block: 'center'});", pay);
wait.until(ExpectedConditions.invisibilityOfElementLocated(By.id("loading-mask")));
driver.findElement(By.id("pay")).click();

If the header still covers it, report the layout issue with the viewport size. More scrolling is not a general fix for a permanently blocked control.

3. The locator selects the wrong copy

A desktop and mobile checkout may both be in the DOM. Scope the locator to the active checkout rather than clicking the first match.

wait.until(ExpectedConditions.elementToBeClickable(
    By.cssSelector("#active-checkout button[type='submit']"))).click();

Prevent it and explain it in an interview

Use the same viewport in local and CI runs, give busy states stable identifiers, and save a screenshot on failure. Start with the obstruction rather than a longer timeout. “The element existed, but another node covered the click point; I waited for that state to end and verified a normal click.”

A removed node instead suggests a stale reference; a missing node suggests NoSuchElementException.

Quick answers

Does elementToBeClickable guarantee the click will land?

No. It checks visibility and enabled state, not whether another element covers the click point.

Should I use a JavaScript click?

Usually no. It bypasses normal pointer interaction and can conceal a problem a user would hit.

Sources

Want a project you can show in interviews?

The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.