In Selenium, what does ElementClickInterceptedException mean, and what does its message name?
answer
- Something got in front of the click
- The driver hit-tests a single pixel
- The specification calls the element obscured
- Read the tag after the last colon
- Other element would receive the click
basics
~20 sThe click target is covered: another element sits over its centre point and would receive the click. The driver's message names that intercepting element, usually its opening tag with id and class, so read it.
solid answer
~40 s`ElementClickInterceptedException` is Selenium 4's mapping of the W3C WebDriver error code `element click intercepted`, which a driver returns from the Element Click command when the element painted at the target's in-view centre point is neither the target nor one of its descendants. On a printing-press console that is usually a sticky press-status bar, an ink-level banner, a toast, or a modal backdrop that is still on screen. The message is the useful part: Chromium's wording is `Element <button id="release-plate">...</button> is not clickable at point (612, 88). Other element would receive the click: <div class="press-status-bar">...</div>`, and the tag after that final colon is the real culprit. The target itself is fine, displayed and enabled, so `isDisplayed()` will not warn you.
code
java · 10 linesWebDriver driver = new ChromeDriver();
driver.get("https://press-console.example/queue");
WebElement release = driver.findElement(By.id("release-plate"));
try {
release.click();
} catch (ElementClickInterceptedException e) {
System.out.println(e.getRawMessage());
System.out.println(release.isDisplayed() + " / " + release.isEnabled());
}
driver.quit();go deeper
Be ready to name the exception on sight and say what causes it: something is painted over the element's centre point. Show that you read the driver's message instead of guessing which element was in the way.
Explain the driver-side check. The browser is asked what is painted at the target's centre point, and anything that is not the target or its own descendant blocks the click. Name the W3C error code behind the class.
An interviewer expects you to turn the named intercepting element into a diagnosis: a modal backdrop still on screen, fixed page chrome over the current scroll position, and an animation mid-flight each imply a different fix.
Own what an intercepted click means for the product. An overlay that steals a real user's click is a defect in the application, and that judgement decides whether teams may route around it in the harness at all.
## What the exception actually reports `ElementClickInterceptedException` lives in the `org.openqa.selenium` package and is the Java binding's mapping of the **W3C WebDriver** error code `element click intercepted`, which carries HTTP status **400**. Selenium 4 speaks the W3C protocol end to end, so this class is not a decision the client library made: the driver put that error code in the response body and `ErrorCodec` turned the string into the class. Other bindings map the same code under their own names. The code means one thing: **the element was found, it was in view, and something else was painted where the click would land.** ## How the driver decides a click is blocked The **Element Click** command's remote-end steps run in a fixed order, and this error comes from one specific step in that order: 1. Scroll the element's **container** into view. 2. If the container is still not in view, return `element not interactable`. 3. If the container is **obscured** by another element, return `element click intercepted`. 4. Otherwise, dispatch the pointer sequence at the element's **in-view centre point**. **Obscured** has a precise definition in the specification: an element is obscured if the *pointer-interactable paint tree* at its centre point is empty, or if the first element in that tree is not an inclusive descendant of the element itself. In plain terms, the driver asks the page what is painted at one pixel — the target's centre — and refuses the click if the answer is anything but the target or something inside it. That has consequences worth knowing: - A **single pixel** decides it. A banner covering most of a wide button but leaving its centre clear does not intercept. - **Transparency does not help.** A modal backdrop at `opacity: 0` is still painted and still wins the hit test. - **`pointer-events: none`** takes an element out of the paint tree, so an overlay styled that way does not intercept. - The check is a **snapshot**. An element still sliding in under a CSS transition can be over the centre point at the instant the driver looks. ## Reading the message The specification fixes the error code and status; the `message` field is free text and each driver words it differently. The Chromium click atom that Selenium ships — `webdriver.chrome.isElementClickable`, in `javascript/chrome-driver/atoms.js` — produces the familiar wording by calling `elementFromPoint` and formatting whatever it finds: | What is painted at the centre point | Verdict | Message | |---|---|---| | The target itself | clickable | none | | A descendant of the target | clickable, with a warning | `Element's descendant would receive the click. …` | | An unrelated element | not clickable | `Element <…> is not clickable at point (x, y). Other element would receive the click: <…>` | | Nothing at all | not clickable | `Element is not clickable at point (x, y)` | Every tag in that text is the element's `outerHTML` with its `innerHTML` replaced by an ellipsis, so you get the opening tag with its `id` and `class` intact and none of the children. That is why the message repays reading: the substring after `Other element would receive the click:` names the culprit outright. Selenium's `WebDriverException.getMessage()` then appends build information, system information and a `Session ID` entry; `getRawMessage()` gives you the driver's own wording without them. ## What the exception does not mean - It does **not** mean the locator failed — that is `NoSuchElementException`. - It does **not** mean the element went away — that is `StaleElementReferenceException`. - It does **not** mean the element is invisible. `isDisplayed()` checks the element's own rendering — `display`, `visibility`, opacity, size, the `hidden` attribute — and never hit-tests, so it returns `true` for a button sitting under an opaque bar. - It does **not** mean the element is disabled. Nothing covers a disabled control, so the click is dispatched and the browser simply does nothing with it. ## Working it through on a print queue A test clicks **Release plate** on job 4471 in a printing-press console and gets: ``` Element <button id="release-plate">...</button> is not clickable at point (612, 88). Other element would receive the click: <div class="press-status-bar">...</div> ``` `press-status-bar` is the console's fixed header. The y coordinate is 88, near the top of the viewport, which says the queue row scrolled up until the button's centre point landed under that header — a geometric problem, and nothing here is going to move on its own. Had the named tag been `<div class="job-toast">`, the reading would be the opposite: a confirmation left over from the previous release is still on screen. The exception type is identical in both cases; only the element named in the message separates them, which is exactly why you read it.
- Does isDisplayed() return false for a button hidden behind a sticky banner?No. `isDisplayed()` is a rendering check — `display`, `visibility`, opacity, size, the `hidden` attribute, an unopened `<details>` ancestor. It never hit-tests, so an element painted underneath an opaque overlay still reports true. Only the click command's own obscured check, which asks what is painted at the centre point, sees the overlay.
- Which exception does ElementClickInterceptedException extend, and why does that matter?It extends `ElementNotInteractableException`, which extends `InvalidElementStateException`, which extends `WebDriverException`. So a `catch (ElementNotInteractableException e)` block swallows interception too. If covered-by-a-banner deserves different handling from never-rendered, catch `ElementClickInterceptedException` first.
- Does the W3C specification dictate the wording of the message?No. It fixes only the error code `element click intercepted` and HTTP status 400; the `message` field is free text. Chromium's drivers produce the "Other element would receive the click" wording from the atom Selenium ships, and other drivers word it differently, so branch on the exception type rather than the string.
The press-status bar is a pane of glass over the console: the Release plate button is perfectly visible through it, but your finger lands on the glass.
saying these in an interview costs you the question
- Says the element was not found on the page
- Blames a stale element reference for an intercepted click
- Claims isDisplayed returns false whenever an overlay covers the element
- Ignores the tag named in the message and retries the click blindly
- Thinks the client library, not the driver, decides the click is blocked