In Selenium, how do you use the element named in an element click intercepted message to find the cause?

## The message is the diagnosis, not decoration An intercepted click reports the same exception type no matter what covered the element, so the exception name alone tells you almost nothing actionable. What separates one cause from another is the **tag named inside the message**. In Selenium 4 the driver hit-tests the target's in-view centre point and reports what it found there, and Chromium's drivers spell it out: ``` 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> ``` Each tag is the element's `outerHTML` with its `innerHTML` collapsed to an ellipsis, so the `id`, `class` and other attributes survive while the children do not. Read that second tag first — it is the only part of the failure that identifies the actual cause. ## Anatomy of the message - **The first tag** is your target, echoed back. Confirms the locator found what you meant. - **The coordinates** are the target's in-view centre point in the viewport. A y of `88` says the collision happened near the top of the window; a y near the bottom implicates something anchored there. - **The tag after `Other element would receive the click:`** is the element painted at that pixel — the interceptor. - **The appended `Build info`, `System info` and `Session ID`** come from Selenium's `WebDriverException.getMessage()`, not from the driver. `getRawMessage()` returns the driver's text alone, which is what you want when you are pulling the interceptor out programmatically. ## What each kind of interceptor tells you | Interceptor named in the message | What it means | Where the fault sits | |---|---|---| | Fixed or sticky page chrome, e.g. `<div class="press-status-bar">` | the target scrolled under permanent chrome | page geometry and scroll position | | A transient confirmation, e.g. `<div class="job-toast">` | feedback from a previous step is still on screen | the ordering of the steps | | A dialog backdrop, e.g. `<div class="plate-modal-backdrop">` | a modal the test believed closed is still open | application state is wrong | | A full-viewport spinner or blocking layer | the console is still busy with the previous command | application state is wrong | | A descendant of the target itself | not an interception at all | the locator could be more precise | The last row matters because it is easy to misread. The Chromium click atom treats a **descendant** at the centre point as a legitimate hit and returns clickable, adding only the warning text `Element's descendant would receive the click.` The click succeeds and the event bubbles to your target, so nothing fails. ## A procedure that works 1. Catch the exception and read `getRawMessage()`, so the driver's own wording is not buried in appended build information. 2. Extract the tag after `Other element would receive the click:` and note the coordinates alongside it. 3. Find that `id` or `class` in the application's own markup and name the component it belongs to — chrome, toast, backdrop, spinner. 4. Ask whether a real user at that viewport size and scroll position would meet the same obstruction. If yes, the console has a defect: an overlay is stealing clicks from a control. If no, the harness put the page into a state a user would not reach. 5. Only then choose the mechanism you use to get past it. Waiting for the overlay to clear and forcing the click through injected script are separate decisions, and both are only sound once you know which element you are dealing with. ## The two messages that are not interceptions - **No `Other element` clause at all.** When `elementFromPoint` returns nothing, the atom prints only `Element is not clickable at point (x, y)`. Nothing is covering the target; its centre point is outside the viewport or under a rendered scrollbar. The problem is geometry. - **`Element's descendant would receive the click.`** As above, this is a warning attached to a *successful* click, not a failure. Treating it as an interception sends you hunting for an overlay that does not exist. ## Do not turn the text into control flow The W3C specification fixes only the error code `element click intercepted` and its HTTP status of **400**. The `message` field is free-form, and drivers word it differently — the Selenium test suite for .NET even asserts on the string as an option rather than a certainty. So: - **Branch on the exception class**, which is stable across every driver and binding, never on a substring of the message. - **Read the message yourself** when diagnosing a failure; it is written for a human, not for a parser. - If you do extract the interceptor's tag mechanically, guard for the case where the pattern does not match, because on a non-Chromium driver it will not. Two clicks that both fail with `ElementClickInterceptedException` in a print queue can be a cosmetic scroll-position artefact and a modal that never closed. The class does not distinguish them; the tag inside the message does.