[🐛 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

[joerg1985]

I had a look at the example and the problem here is the useage of ::before and ::after css-pseudo-elements. These elements are the ones a human does interact with, therefore your automation should also try to interact with them. Otherwise you might be able to click the element, but a human is not able to click.

The webdriver is not aware of these css-pseudo-elements, so you can not get a reference to them and interact with them directly. Changing the IsDisplayed implementation will not help here for the following reasons:

• the webdriver does use another logic to detect the interactability so it will still raise a ElementNotInteractableException
• the input element is currently hidden using the opacity, this could change in the future e.g. to setting display: none
• the lbl2 element has a height of 0, so it will fail due to this too

So we have to workaround when handling these elements, one way to do so is to use the Actions API. The Action API will not scroll to the element or check anything, it will just performe the given commands. I am not a C# dev, but this should work in this case:

  IWebElement label = driver.FindElement(By.Id("lbl2"));
  new Actions(driver)
      .MoveToElement(label, 0, 10)
      .Click()
      .Perform();

[ysiivan]

The problem of how to assess and wait for "clickability" still remains.

[ysiivan]

So we have to workaround when handling these elements, one way to do so is to use the Actions API. The Action API will not scroll to the element or check anything, it will just performe the given commands. I am not a C# dev, but this should work in this case:

  IWebElement label = driver.FindElement(By.Id("lbl2"));
  new Actions(driver)
      .MoveToElement(label, 0, 10)
      .Click()
      .Perform();

This workaround does not work for lbl2. Still throwing OpenQA.Selenium.ElementNotInteractableException: element not interactable

[joerg1985]

The problem of how to assess and wait for "clickability" still remains.

You are missing a feature to access CSS Pseudo-Elements inside the webdriver spec, so opening a feature ticket in https://github.com/w3c/webdriver/issues is in my mind the correct way to proceed. As soon as the spec is updated, the drivers can implement this and selenium can integrate this. @diemol what do you think is this the correct way to continue?

This workaround does not work for lbl2. Still throwing OpenQA.Selenium.ElementNotInteractableException: element not interactable

I have tested with java and for me the snippet below does work. @nvborisenko Could you please check this with the dotnet binding? The check2.html can be found here check2.zip

public static void main(String[] args) throws Exception {
    org.openqa.selenium.chrome.ChromeDriver cd = new org.openqa.selenium.chrome.ChromeDriver();
    cd.get("file:///C:/tmp/check2.html");

    var lbl2 = cd.findElement(org.openqa.selenium.By.id("lbl2"));

    new org.openqa.selenium.interactions.Actions(cd)
            .moveToElement(lbl2, 0, 10)
            .click()
            .perform();

    org.junit.jupiter.api.Assertions.assertTrue(
            cd.findElement(org.openqa.selenium.By.id("myCheckbox2")).isSelected());

    cd.quit();
}

[shivkantkumar098]

Hello @ysiivan

Fix clickability check to ignore opacity when waiting for an element

The current isDisplayed() method in Selenium does not handle cases where opacity is set to 0. If you want to disregard opacity when checking for clickability, you could expose an additional option or parameter, such as ignoreOpacity, to force the clickability check to ignore opacity values.

You can propose a solution where Selenium provides an explicit mechanism to ignore opacity when waiting for an element to be clickable.

If you're comfortable contributing code to Selenium, you can modify the method responsible for determining if an element is clickable. You might update or create a new method that does not consider opacity: 0 when evaluating whether the element is clickable.

For example:

You can add an optional parameter in the existing method that checks for visibility and clickability, which would allow the user to ignore opacity.

public boolean isClickable(WebElement element, boolean ignoreOpacity) {
    if (ignoreOpacity) {
        // Check if the element is interactable without considering opacity
        return element.isDisplayed() && element.isEnabled();
    } else {
        // Use the default method (checking opacity)
        return element.isDisplayed() && element.isEnabled() && getOpacity(element) > 0;
    }
}

Expose this feature via WebDriverWait:

You could extend or modify the WebDriverWait functionality to accept this new flag when waiting for an element to be clickable

[github-actions]

This issue was closed because we did not receive any additional information after 14 days.