Have you ever got this problem when writing web driver tests, the element is at an un-clickable point because another element got in the way? This has got to be one of the most frustrating error messages in the world of web driver. The framework is essentially telling you, ‘Hey I found the thing you’re looking for, but I’m not going to click it because there’s something in the way.’ It’s even worse when the thing that’s in the way is not a visible thing or only partially obstructing the view.

Solving the Problem the right way

There are a few ways to deal with this problem. The preferred method of course is to understand what exactly is blocking the element your test is trying to click on. Most of the time we need to have the tests wait for something to move out of the way or something to appear before we can click on the item we’re trying to automate.

This could be a modal window blocking the button, or perhaps an animation that isn’t fully closed or finished when the test is attempting to click it. If the test is only sometimes failing for this error, it’s usually a good indicator of having to wait a bit longer for a previous action to ‘complete’ before executing your new action.

Although if the element you’re trying to click on is a descendant element of the element that’s ‘blocking’ the click you may need to change the locator. This can be confusing because the element you want to click is a child of the element that will ‘intercept’ the click. To fix this simply include the parent element in the selector your using to locate the element. For example let’s say you have a button element with a selector like: button.item-name .

The error that your getting might be something like:

Element with the selector 'div' is blocking the click

Simply update the button selector to be div button.item-name to get solve the issue.

Brute force Java-script injection

Sometimes no amount of waiting or selector manipulation is going to solve the problem. Either the application is broken in some way to obstruct elements you want to click, or there is just something else. Perhaps the platform your testing on in your continuous integration environment is different enough that this problem only manifests there. Or perhaps you’re waiting for some changes to the design of the screen to be pushed through. No matter the reason, sometimes you just want to move on with your tests. That’s when you know it’s time to pull out the big guns.

We want to hide the obstructing element so we can click on the thing we need.

browser.execute(() => {
  document.querySelector('div.obstructing__element').style.display == 'none';
});
button.click()

This will completely hide the element blocking your element. This makes it so your tests can click the element you need to move on with your tests.

There are some on stack overflow that say removing the element is better, but removing the offending element could potentially change the layout of the page significantly. Enough times I’ve tried to remove the element and the page layout alters enough that it becomes a goose chase of removing elements, just to move on with your test. Just change the display of the offending element to effectively allow your test to move on.

Conclusion

There you have it, hopefully now you’re armed with enough ammo to go out and conquer the world of test automation a little more confidently.