Element Not Interactable Exception how to solved it

Robot Framework
1 
    [Arguments]   ${card_name}
     Wait Until Element Is Visible  ${loc}  ${short_time}
     @{Locators_common} =  Get WebElements  ${loc_}
      Click Element  ${Locators_common}[${card_name}]
     Wait Until Element Is Visible  ${loc_Validation}  ${short_time}

hi i am new at robot framework
i want to used element from locator_common list on the basic of their index so
when i used click element and pass ${Locators_common}[${card_name}] that time ElementNotInteractableExceptionexcepation showd ho to deal it ?

2

Hi @rahul12

Error your receiving is thrown to indicate that although an element is present on the HTML DOM, (which would suggest the locator looks to be valid) but it suggests it is not in a state that can be interacted with. And the “Wait Until Element Is Visible” is a good start and should normally resolve the issue in most, could you confirm if the element you’re wanting to ‘Click’ is out of view on load? as you may have to scroll this into view before interacting with it, this can be achieved with the below as something to try

SeleniumLibrary:
Scroll Element Into View ${Locators_common}[${card_name}]

You could wrap that in [Run Keyword And Ignore Error ] which is part of the built-in library, depending on your error handling

But in terms of fully understanding where the issue may be sharing the log for where it’s falling over and possibly a snippet of the dom for the element you’re trying to click, could be helpful in helping you if the above doesn’t resolve where the exception is thrown.

3

thanks
but after used Scroll Element Into View ${Locators_common}[${card_name}]
same exception will showed ElementNotInteractableException: Message: element not interactable:

1 Like
4

→ Are you able to provide a snippet of the dom and RF logs for where it’s falling over, if it’s a public site then providing the Url and for which element you’re having trouble would be helpful as mentioned… ←

But, I’m almost certain the problem is this below in bold as it will be by index you’ll need to use to return that item (element) from the list of elements, and then do some form of a check to make sure its the correct element you want to interact with, based on what’s been given:

@{Locators_common} = Get WebElements ${loc_}
Click Element ${Locators_common}[${card_name}]

Hard not to guess when there’s not much given but it will be a 0-based index, and not knowing what “card_name” holds, could be 0+ or a string value…

I guess there are a number of things you could do, if all cards use the same/part locator + ${card_name} you can remove the line of @{Locators_common} = Get WebElements ${loc_} and then, set a common variable for ${cards_common}, then do the below:

Click Element ${cards_common}//*[@text='${card_name}']

You’ll just need to figure out what that common part is, the dom is a good place to figure out what that common XPath may look like.

2 Likes
5

Thanks daryl

2 Likes
7

xpath = (//input[@id=‘signInFormUsername’])[2] it does not highlight the element

8

Hi,

You might use the [1] element which is the one visible and interactable.
The second one might be hidden and used/built for other purposes (other login type or frame not displayed currently)
However you didn’t mentioned what fails ? I assume the ‘Input Text’ keyword ?

Verify in the upper levels of the xpath if the //input is not in an iframe or shadow-dom.
In the iframe case you should select it first to “enter” the frame and interact with its content.
Then don’t forget to Unselect Frame after to continue interaction after login.

For shadow-dom this would be more tricky depending of the used libraries.

Regards.
Charlie

9

Hi Again,

Well it’s none of the ideas above, I went to your page there’s no iframe nor shadow-dom.
I have it working with your xpath the first time in debug, but not the second time…
I don’t really now why but sometimes the needed and interactable input is the [1] and sometimes the [2], and seems to switch randomly.

Finally I think you’ll need the precise the xpath in a more accurate way… You might know better what’s important for you, but this works :

Login Test
    Open Browser    https://i-fi.ai/login    chrome
    Maximize Browser Window
    Input Text    //div[contains(@class, 'visible-md visible-lg')]//input[@id='signInFormUsername']    TestingName

I only found a difference in the upper div with visible-md visible-lg attribute, and oddly both input have a hidden attribute.

Then if the attribute is not a strong solution enough, you could also use only one simple xpath in a try/except (even though it’s some kind of ugly workaround) :

TRY
    Input Text    (//input[@id='signInFormUsername'])[1]   TestingName1
EXCEPT
    Input Text    (//input[@id='signInFormUsername'])[2]   TestingName2
END

Regards.
Charlie

3 Likes
10

Thanks a lot @CharlieScene . its working!!!

2 Likes