Command Failure Signals

## 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.