Why is am i getting 'element not interactable exception' during my Selenium test?

Ask a Question
,
1

I’m running Selenium tests on a web application using Chrome on a Windows 10 machine. I’m trying to interact with a button element, but keep encountering the

“org.openqa.selenium.ElementNotInteractableException: element not interactable” error. I’ve ensured the element is visible using waits, but the error persists.

The page uses dynamic content and JavaScript heavily. I’m not sure why this exception is being thrown and how to resolve it. Can anyone explain what’s happening and how I can fix it?

2

I faced this issue while working on a project that involved testing a dynamically loaded page. Initially.

I thought using WebDriverWait for visibility would solve it, but it didn’t help. It turns out the element may be visible but still not interactable due to overlapping elements or timing issues.

One alternative approach is to use JavaScript to directly interact with the element. This bypasses WebDriver’s standard interaction methods, which can fail in such cases. Here’s how you can do it:

Here is the snippet that worked for me:

JavascriptExecutor js = (JavascriptExecutor) driver;
js.executeScript("arguments[0].click();", driver.findElement(By.id("buttonId")));

The code above executes JavaScript directly in the browser context to click on the element. This method typically works even if the element is covered by another element. However, it should be used cautiously as it bypasses the usual checks that Selenium does.

Just make sure that using JavaScript doesn’t become a habit, as over-reliance can hide other underlying issues in the UI flow that could affect user experience.

3

This is a common issue that can be really frustrating, especially when everything seems visible.

The root cause of an org.openqa.selenium.ElementNotInteractableException is usually that the element you’re trying to interact with is not in an interactable state.

This often happens if the element is off-screen, covered by another element, or not yet ready for interaction.

One straightforward solution is to wait until the element is interactable. Selenium provides WebDriverWait which can help ensure the element is fully ready.

Use ExpectedConditions to wait until the element is clickable. Here’s a simple way to do that:

WebDriverWait wait = new WebDriverWait(driver, 10);
WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.id("buttonId")));
element.click();

This code essentially waits up to 10 seconds for the element to become clickable. If it becomes interactable within that time, it clicks the button. Otherwise, it throws a timeout exception, giving you more insights.

Make sure the “buttonId” matches the actual ID of the element.

A pro tip: Ensure that there are no CSS styles making the element non-interactable or JavaScript transitions that need more time. Adjust the wait time as necessary based on the complexity of your page.

4

In my experience as a QA lead, org.openqa.selenium.ElementNotInteractableException can stem from several architectural decisions in web development.

High reliance on JavaScript and dynamic content means the DOM is frequently updated, which can leave elements in a non-interactable state temporarily.

An advanced strategy is to check if the element is not only visible but also enabled and focusable.

This can involve a combination of checking attributes and using JavaScript to determine the element’s state:

Here is the snippet that worked for me:

WebElement element = driver.findElement(By.id("buttonId"));
boolean isEnabledAndFocusable = (boolean) ((JavascriptExecutor) driver)
    .executeScript("return arguments[0].enabled && !arguments[0].hidden;", element);
if (isEnabledAndFocusable) {
    element.click();
}

This script checks if the element is both enabled and not hidden using JavaScript. It’s a more comprehensive check before interacting with the element, ensuring code robustness.

Remember to verify your page’s responsiveness settings. elements might not be interactable on smaller viewports due to design constraints.

Understanding these differences can save you debugging time and enhance test case reliability in diverse environments.