[🐛 Bug]: elementToBeClickable wait condition fails on elements with opacity 0

[ysiivan]

What happened?

The condition to evaluate the "clickability" of an element considers whether the element is Displayed, which does not regard elements with an opacity of 0 as Displayed.

The proposal in the closed 14030 was to make Displayed disregard the opacity. I understand the arguments on both sides. However at the end of the day, the actual problem is still not resolved - waiting for "clickability", as it is now, is unreliable. The original post was about React, I just encounter the issue in an Angular app. Clickjacking or not, it seems the technique is apparently being used. I can't judge whether this is a right or a wrong way of doing things, but so should not Selenium.

All this aside - the bottom line is - opacity does not play a role in "clickability".

If Displayed is to stay as it is, then how can we properly ascertain "clickability"?
I'm not the best at reading minified javascripts, but it seems is-displayed.js "atom" is already wired to take an optional parameter for ignoring opacity. Perhaps expose a way to use that?

How can we reproduce the issue?

Have an element with opacity 0 and try to wait for it to become clickable.

Relevant log output

N/A

Operating System

N/A

Selenium version

N/A

What are the browser(s) and version(s) where you see this issue?

Chrome

What are the browser driver(s) and version(s) where you see this issue?

130.x.x.x

Are you using Selenium Grid?

No

[github-actions]

@ysiivan, thank you for creating this issue. We will troubleshoot it as soon as we can.

---

Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

[joerg1985]

@ysiivan Before starting the discussion on this again, please provide a valid exampe page and some code to reproduce this. Without a concrete example it is hard to tell what is the correct way of dealing with things.

[github-actions]

Hi, @ysiivan.
Please follow the issue template, we need more information to reproduce the issue.

Either a complete code snippet and URL/HTML (if more than one file is needed, provide a GitHub repo and instructions to run the code), the specific versions used, or a more detailed description to help us understand the issue.

Note: If you cannot share your code and URL/HTML, any complete code snippet and URL/HTML that reproduces the issue is good enough.

Reply to this issue when all information is provided, thank you.

[ysiivan]

@joerg1985 The app I encountered this with is not publicly accessible. I'll see if I can something else to demonstrate.

[ysiivan]

@joerg1985 Attached is a static html file (zipped) that demonstrates the issues:

1. How to properly wait for "clickability"?
   Currently we use something like this:

var element = wait.Until(SeleniumExtras.WaitHelpers.ExpectedConditions.ElementToBeClickable(by));

Which fails for either of the two checkboxes on the page. The wait delegate uses Displayed to evaluate "clickability" and Displayed is false because the checkboxes have opacity of 0.
That said, if I go straight for the checkboxes without waiting, it will work. But this really is not a general solution, because we'd lose other cases when we do need to wait for an element to become "clickable".
I understand that the SeleniumExtras .NET package was split from Selenium some time ago. That's fair. But what's the correct way to assess "clickability" then?

2. The checkboxes can also be worked by clicking their labels (or rather this is how these custom controls are worked).
   However, while the top one has a label with text and Selenium can click on it, the second one, which is without text, causes Selenium to throw an OpenQA.Selenium.ElementNotInteractableException exception (wrong visibility assessment?).
   So a solution to wait for the labels to become "clickable" instead of the (transparent) checkboxes doesn't work either.

Both controls are visible on the page and can be clicked on manually.
check2.zip

[liam413-crypto]

This bug is hard to fix.