In Selenium 4, how do ElementClickInterceptedException and ElementNotInteractableException differ and relate?
answer
- One of them is broader than the other
- Covered versus never reachable at all
- Typing can raise only one of them
- Check the inheritance before writing catch
- Intercepted is a subclass of not-interactable
basics
~20 sInterception means something is painted over the target. Not-interactable means the target itself cannot be reached at all: not rendered, not scrollable into view, or not focusable for typing. In Selenium 4 the intercepted class extends the not-interactable one.
solid answer
~40 s`ElementNotInteractableException` is the broad case, mapping the W3C error `element not interactable`: the element was located but the command could not reach it, because Element Click could not get it into view or Element Send Keys found it is not keyboard-interactable, as with a `<label>` or a `display: none` field. `ElementClickInterceptedException` is the narrow case: the element *is* in view, and something else is painted at its centre point. In Selenium 4's Java binding the narrow class extends the broad one — `ElementClickInterceptedException` extends `ElementNotInteractableException` extends `InvalidElementStateException` extends `WebDriverException` — so a catch on the parent quietly swallows interception. If a print-queue test should tolerate a toast covering a button but fail loudly when the button never renders, catch the intercepted class first.
go deeper
Recall that both mean the command refused to touch the element, and that one of them is specifically about something covering it. Be able to say which one a click can raise and which one typing can raise.
You are expected to explain the split: reachable-but-covered against not reachable at all, the W3C error code behind each, and the fact that one class extends the other in Selenium 4's Java binding.
Show what the inheritance costs in real code. A broad catch collapses a toast stealing the click and a control that never rendered into one branch, hiding a genuine application bug behind whatever recovery you wrote.
Frame the tradeoff across a whole suite: how precise exception handling has to be before failures stay diagnosable, and where the line sits between harness tolerance and letting a real defect surface.
## Two error codes, two different situations Both classes live in `org.openqa.selenium` and both map **W3C WebDriver** error codes, but they describe opposite kinds of failure. **`ElementNotInteractableException`** maps `element not interactable`. The element exists and was located successfully, but the command could not reach it at all: the click command could not get its container into view, or — on the typing path — the element is not **keyboard-interactable**, meaning it has no focusable area and is neither the `<body>` nor the document element. **`ElementClickInterceptedException`** maps `element click intercepted`. Here the element *was* reachable: the driver scrolled it into view and then found something else painted at its in-view centre point. | | `ElementNotInteractableException` | `ElementClickInterceptedException` | |---|---|---| | W3C error code | `element not interactable` | `element click intercepted` | | HTTP status | 400 | 400 | | The element is… | not reachable at all | reachable but covered | | From Element Click | when the container is still not in view | when the container is obscured | | From Element Send Keys | when it is not keyboard-interactable | never | | From Element Clear | when it is not interactable | never | | Place in the hierarchy | the parent class | the subclass | ## Where each one is produced The **Element Click** remote-end steps produce both, in this order: 1. Scroll the element's container into view. 2. Still not in view, so return `element not interactable`. 3. Obscured by another element, so return `element click intercepted`. 4. Otherwise, dispatch the pointer sequence. **Element Send Keys** and **Element Clear** produce only the first of the two. Send Keys waits for the element to become keyboard-interactable and returns `element not interactable` when it never does; Clear waits for it to become interactable and returns the same code. Neither path performs an obscured check, and that asymmetry is the most useful thing to carry away: - A banner painted over a print-queue note field **does not** stop `sendKeys` — the keystrokes go to the focused control regardless of what is drawn on top of it. - The same banner over the same field **does** stop `click()` on it. - So a step that types into a field successfully and then fails on the neighbouring **Release plate** button is behaving exactly as specified, not inconsistently. ## The inheritance, and why it bites In Selenium 4's Java binding the chain is `ElementClickInterceptedException` → `ElementNotInteractableException` → `InvalidElementStateException` → `WebDriverException` → `RuntimeException`. Because the narrow class extends the broad one, this catch handles both: ```java try { driver.findElement(By.id("release-plate")).click(); } catch (ElementNotInteractableException e) { // this also catches ElementClickInterceptedException } ``` All of these are unchecked exceptions, so nothing in the compiler flags the overlap. The practical rules: - Catch `ElementClickInterceptedException` **first** when the two cases deserve different handling. - Catch `ElementNotInteractableException` on its own only when you genuinely mean "could not be interacted with, for any reason". - Catching `InvalidElementStateException` is broader still: it also covers `clear()` on an element that is neither a resettable form control nor content-editable. ## What the split is worth on a print queue The two errors describe different states of the press console, and collapsing them hides one. "A toast from the previous job is still covering **Hold job**" is a page that rendered correctly and merely has stale chrome on it. "The **Hold job** button never came into view" is a page where the queue row is missing, collapsed to zero height, or rendered outside the scrollable area — a genuine rendering fault. A single `catch (ElementNotInteractableException e)` around the click treats both as the same event, so the second one disappears behind whatever handling you wrote for the first, and the console ships with a row that never renders. ## Neither one is a lookup failure - If the locator matched nothing, you get `NoSuchElementException` — a different branch of the hierarchy entirely. - If the element was found and then detached from the document, you get `StaleElementReferenceException`. - Both of the errors discussed here occur *after* a successful lookup, which is itself information: the markup exists and the selector found it, so the problem is the element's state or what is drawn over it, never the selector.
- Which of the two can sendKeys raise, and why only that one?Only `ElementNotInteractableException`. Element Send Keys scrolls the form control into view and requires it to be keyboard-interactable, meaning it has a focusable area or is `<body>` or the document element. There is no obscured check on the typing path, so a banner over an input never produces an intercepted error from `sendKeys`.
- Why is catching ElementNotInteractableException around a click risky?Because `ElementClickInterceptedException` is a subclass, so one catch handles both. Code written to tolerate an element that has not rendered yet will silently tolerate a modal that stole the click as well, collapsing two very different application states into one handler.
- Where does InvalidElementStateException fit into this?It is the shared parent of both, mapping the W3C error `invalid element state`, and it is what Element Clear returns for an element that is neither a resettable form control nor content-editable. Catching it around a single click is broader still and rarely what you mean.
saying these in an interview costs you the question
- Treats the two exception names as interchangeable synonyms
- Says sendKeys raises an intercepted error when a banner covers the input
- Believes the two classes are unrelated siblings under WebDriverException
- Assumes not-interactable always means the element is missing from the DOM
- Catches WebDriverException around every click and calls it handled