Input Text sometimes doesn't send all the keys

[lubosjerabek]

Steps to reproduce the issue

1. Use Input Text id=MyElementId 53.63
2. Assert the element value

Code example:
${myValue} = Set Variable 53.63
Wait Until Element is Visible id=MyElementId ${global_timeout}
Wait Until Element is Enabled id=MyElementId ${global_timeout}
Input Text id=MyElementId ${myValue}
Textfield Value Should Be id=MyElementId ${myValue}

Expected result:

• Value has to match the input

Actual result:

• Value does not match the input
• Sometimes the value seems to be cut from the beginning so I'm getting "shorter" strings
• In this case the field value was 3.63 instead of 53.63 (first character on the input was missed)
• This does not happen in 100% of the cases but it messes the test results

I have a very simple (and really not clean) workaround in my SeleniumLibrary extension class now which sends the keys checks for the element value and if the value differs from the original text it clears the element value and tries again.

Environment

Browser: headless chrome=71.0.3578.80
Browser driver: chromedriver=2.44.609538
Operating System: Windows Server 2012 R2
Libraries

• Robot Framework: robotframework==3.0.4
• Selenium: selenium==3.141.0
• SeleniumLibrary: robotframework-seleniumlibrary==3.3.1
• Interpreter: Not sure where can I find this - if it's a dealbreaker, please advise:)

[aaltat]

Would you be able to demonstrate the problem with a example that I can also run? If not, could you run the test with the --loglevel trace set from the command line and show the keyword logs from the Input Text keyword?

[lubosjerabek]

@aaltat We're not doing anything unusual with the Input Text - generated data is always type of string. I would also say that this is very intermittent - we have 2.2k tests which use the "Input Text" keyword maybe 10k times per run.

When I use the Trace log level I cannot see anything (the keyword now passes when running locally.) I am a bit worried to use this in our overnight test config (as the output file would be just too big) but I will leave this in my local config and let you know if I notice anything.

By the way, I also updated Chromedriver to 2.45 - not sure if the issue could be on webdriver side.

[aaltat]

I would have been interested to see what the Selenium logging is saying, which are also visible DEBUG level, if that is easier for you. The logging shows also what string is send to the browser (driver) direction. But looking at the code, keyword is a simple wrapper on top of the Selenium API calls, Which makes assume that problem is somewhere in downstream.

This feels quite a typical problem, example input element might be visible and enabled but it not ready to receive the text, because some JavaScript is running in the background which can make you lost few keys. Also it might be that clear() method triggers some event in the field and causes some instability for inputting the text to the input element.

[aaltat]

Do you still think that this is a problem in the SeleniumLibrary or can we close the issue?

[aaltat]

Closing due inactivity.

[chicken-suop]

I am also experiening this. Please reopen. It happens with a very simple test case, but only intermitably. My guess is it's a timing issue

Wait Until Element Is Visible    //*[@id="something1"]    30
Sleep    1s
${something1}    Get Text    //*[@id="something1"]
Click Element Wait    //*[@id="auto-work-tasks"]
# Sleep until previous dialog is closed
Sleep    2s
Wait Until Page Contains Element    //*[@id="dialog"]    30
# Enter data
Click Element Wait    //*[@id="btn"]
Input Text    //*[@id="forminput"]    CH123
Click Element Wait    //*[@id="btn1"]

[aaltat]

Next time please open a new issue. But would you be able to demonstrate the problem with a example that I can also run? If not, could you run the test with the --loglevel trace set from the command line and show the keyword logs from the Input Text keyword? I am interested to see what the Selenium logging is saying, which are visible DEBUG level, if that is easier for you. The logging shows also what string is send to the browser (driver) direction.

[pekkaklarck]

This kind of error can occur due to a bug in the app itself. It might be that it gets characters so fast that it doesn't handle them. I guess it would be possible to enhance Input Text to accept a delay it uses between characters it sends, but it would feel a bit strange to do something only to workaround a bug in the tested app.

Notice also that instead of //*[@id="something"] you can simply use something or id:something. Simpler and most likely also a bit faster to execute. See the library docs for more details.