Consider the following <select>
from an internal Selenium test page:
<select id="invisi_select" style="opacity:0;">
<option selected value="apples">Apples</option>
<option value="oranges">Oranges</option>
</select>
It is used to simulate an invisible element as the id
suggests, which is done by setting opacity
to 0.
Although the element is not visible, a user can actually interact with it. If I open the page in a browser and click on the element's position, the select menu opens. I believe this is also why WebElement#isDisplayed()
returns true
for this element, which is also what these old Selenium issues suggest:
- https://github.com/seleniumhq/selenium-google-code-issue-archive/issues/1610
- https://github.com/seleniumhq/selenium-google-code-issue-archive/issues/1941
To execute actions such as clicks, we recently switched to the Java interactions API for several reasons, e.g., to prevent ElementClickInterceptedException
s. (Please note that this is not about refactoring a bunch of Selenium tests, this happens in the context of a generic action executor that operates on top of the Selenium API.) However, if I do something like:
WebElement applesOption = /* get apples option */
new Actions(webDriver).moveToElement(applesOption)
.click()
.perform();
Moving to the element throws the following exception:
org.openqa.selenium.JavascriptException: javascript error: Failed to execute 'elementsFromPoint' on 'Document': The provided double value is non-finite.
I guess this is because elementsFromPoint()
via the WebDriver Actions API seems to return a "non-finite" double for transparent elements like this?
Is there a way to prevent this from happening when using Actions
? Maybe, in addition to checking if the element is clickable (ExpectedConditions#elementToBeClickable(...)
), I would have to parse—which sounds horrible—attributes such as opacity
?