Element <...> is not clickable at point (...) because another element <...> obscures it

[jonas]

My biggest problem with newest selenium library and geckodriver:

With selenium 3.141.59 and geckodriver: 0.24.0 (both newest)

I have this simple page with a sticky overlay (html srs in attachment [minimized_page2.html]):

The page is bigger than the screen and so selenium has to scroll. But it scrolls only until the element (dropdown box) comes into the viewport.

There it is not clickable and I get the:

org.openqa.selenium.ElementClickInterceptedException: Element <select class="property_cultureProcessingAction"> is not clickable at point (138,956.5) because another element <input id="finishButton" type="submit"> obscures it

What I wonder, if I am the only one with such a problem. My solution is a really stupid wrapper around click, where it scrolls after it could not click:

       public void mouseClick(WebDriver driver, By locator) {

driver.findElement(locator).click(); }

} catch (WebDriverException ex) {

try {

scrollToCenterOfPage(driver, locatorToUse);

driver.findElement(locatorToUse).click();

System.out.println(

"Successful via scrolling into view and click for locator: "

+ locator);

} catch (ElementNotVisibleException enve) {

throw new ElementNotVisibleException("Element not visible);

}

}

}

I have created a ticket in: https://github.com/mozilla/geckodriver/issues/1441 and found that he basically claims that it is selenium's fault, as he does not know what searchByIndex excactly does (ok ... you have to read between the lines, there)

But it does not really matter what kind of element is underneath (drop down menu, clickable img etc). Anything underneath  the sticky element is not directly clickable! and needs to be scrolled first. For me this is a bug! As the pages I am testing have sticky elements and as the page can grow or shrink, I basically need to wrap all selenium interactions similar to the above code. This is really really really annoying in my case!

I have attached the java class with the test, where basically you only need to replace the code to the geckodriver and to the path to the minimized page, once you installed the libraries (testng,selenum etc.)

You can also find the complete log and the source code of the webpage.

Thanks who ever looks at this.

Jonas

Operating system: Linux or Windows 10

Firefox 60 ESR

[jonas]

Sorry: my question is: is this really the only way of writing tests? Scrolling in order to prevent obscured??? To me this is a bug! I just don't know if in selenium or geckodriver.

[Mark Collin]

Well based on your screenshot, it's right the Submit button is obscuring the drop down.  You may want to get your devs to fix that problem.

[Karthik Deepan]

May I know, why you want to scroll down till you see the dropdown?.  Selenium can handle any element present in DOM, either it is in your view or not.  

On Tue, Mar 12, 2019 at 10:12 PM jonas <jonas.tr...@gmail.com> wrote:

Sorry: my question is: is this really the only way of writing tests? Scrolling in order to prevent obscured??? To me this is a bug! I just don't know if in selenium or geckodriver.

--
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-user...@googlegroups.com.
To post to this group, send email to seleniu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-users/30cfe64d-93cd-491b-b523-577a5f7f5d28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jonas]

On Tuesday, March 12, 2019 at 5:49:16 PM UTC+1, Mark Collin wrote:

Well based on your screenshot, it's right the Submit button is obscuring the drop down.  You may want to get your devs to fix that problem.

What they should do differently? Imagine there is a page where you want to see at all point a button, no matter where you are when you are scrolling. (in our case it is box with Cancel/Delete/Save) .

Should the stickiness in this case defined differently?

[jonas]

On Tuesday, March 12, 2019 at 5:54:01 PM UTC+1, Karthik Deepan wrote:

May I know, why you want to scroll down till you see the dropdown?.  Selenium can handle any element present in DOM, either it is in your view or not.  

Well, I try it without and then it gets the  "Element <...> is not clickable at point (...) because another element <...> obscures it" Exception. I catch the exception and then only it scrolls. Believe me, with our pages it shows that it scrolls quite a bit. (some pages are quite long and wide)

But if you try the test example, I have attached, it should also throw the same exception with the newest selenium and geckodriver.

[Karthik Deepan]

Not sure if this would help you, but check on that JavaScript executor part in the answer

https://stackoverflow.com/questions/49921128/selenium-cant-click-element-because-other-element-obscures-it

--

You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-user...@googlegroups.com.
To post to this group, send email to seleniu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-users/35635388-8f8b-4df8-8c4b-f82e9db71525%40googlegroups.com.

[sachin patil]

Agree with Karthik Deepan

Best Regard
Sachin Patil
+91-9552619077

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-users/CABym8RLWV1M1%2Bpa9Ww07x5wua1e%3DeLSZqSngYRTVvPVNrugaCA%40mail.gmail.com.

[Vicknesh Pakshirajan]

I am also facing this issue from past two days.The element is not clickable until it comes into the viewport. I used JavascriptExecutor and wait as per the below thread and it worked.

https://stackoverflow.com/questions/11908249/debugging-element-is-not-clickable-at-point-error

But the issue here is, I have to incorporate the change to every instances where I use click in my application, which requires a large effort. 

[jonas]

The solution with hiding the sticky overlay works (as pointed out in the link from Karthik).

However, imagine: we have this show pages which can be edited. When you edit them, you can scroll and at all point you want to see this sticky overlay with the 3 buttons: cancel, save and delete.

If I remove the overlay, I can not access it anymore either, as it is hidden and it gets: ElementNotInteractableException. But I need to save etc.. Ergo, I needed to bring it back again.

@Vicknesh: I also had once the javascript click solution in earlier times. It has a different perception of what is displayed and therefore is working better.

Anyway, after all I like to see it as a BUG or not yet fully matured software selenium!!!

I liked the guy who said, why does selenium even have a click when isDisplayed and isEnabled not even work in all situations!

The best practice for me is: wrap any interaction with selenium. Like that you have the full control and you can still facilitate the code, if selenium is working once properly.

[Jim Evans]

The scrolling behavior of Selenium (or more precisely, WebDriver, upon which Selenium is based) is dictated by a W3C Specification, which dictates that the element to be clicked should be scrolled exactly where it’s being scrolled in your case. There is no way to know, in the generic case, that is, one that works for every web page and every user, if there is an absolutely positioned element that would obscure the target element until the click is performed. I understand your frustration, but if you have a suggestion that would work for every single page, everywhere, I welcome you to open a pull request against the specification on Github. Categorizing the (spec-compliant) behavior as a bug is inaccurate, and frankly, unfair.

[jonas]

I did not know that scrolling the element exactly to a certain position is by W3C Specification. I would have though it should scroll until it is visible as humans do, too.

[Mark Collin]

The key thing here is that you clearly have a user interface that has been badly designed and this is what's causing you problems.  It makes no sense to absolutely position a control element over the related input elements.  This is a problem you should be pushing back to your developers to get them to fix.  As a human I would have the same problem trying to click on that element that Selenium does.  I could probably fiddle about with scrolling a bit more to try and get it working, but that is me implementing a workaround, much in the same way you have a code workaround that performs some extra scrolling.

Your assertion that Selenium should scroll until it is visible like a human sees it, is quite frankly ridiculous.  Us humans have something immensely powerful stuck in our heads to help us perform all sorts of calculations on the fly and quickly adapt to new and never before seen problems as they come up.  Expecting Selenium to act like a human brain is really not feasible.  Secondly what is your definition of visible?  I suspect it's not the same as my definition of visible, which I suspect is totally different to somebody who suffers from Protanopia, which again is probably totally different to somebody who suffers from Tritanopia (we could go on indefinitely here). 

Selenium has a clear definition of how the scrolling behaviour works and in this case it is following it.

[jonas]

@Mark Collin

I removed everything unnecessary from the web page and some of it I replaced by dummy entries in order to reduce it to the error. Maybe it does not make sense like this anymore, but the original webpage makes sense to me. To me it makes sense to have an absolutely placed sticky element on the viewport. E.g., if you have a long page where you want to have at any scroll point a button to click, in order not to scroll all the way down or up to click it.

If the implementation I posted at the beginning with the "completion-buttons-panel-sticky-wrapper.sticky" and the div element is the proper way to so, I don't know as I am not a front end developer. If there is a better example, I am happy to present it to our frontend developers.

My solution, as I posted before, is, that it clicks and if it gets a ElementNotVisibleException, it scrolls the element to be clicked in the middle of the viewport. It does not resolve everything so far, but it looks in my test runs already much better. You convinced me, that this behavior should not be in selenium, as it is not according to spec, but it is worth to write it down.

[[It is funny that you mention how immensely powerful humans are. I had a good laugh, thanks! It is much easier to think that humans are dump, then you can at least explain a view things in the world]]

[jonas]

Sorry, I meant more globally ... after reading about New Zealand.