input text sometimes doesn't send all the keys (revisited)

It seems we are seeing the symptom reported by closed issue #1285. As requested in the original issue, I’ve attached a log file with --loglevel trace in effect. Here are the details…

When we try to use RobotFramework+SeleniumLibrary under Chrome, we lose characters that are sent to the web page as input text. Here’s a simple example robot script that produces the symptom for us:

*** Settings ***
Documentation     Simple example using SeleniumLibrary.
Library           SeleniumLibrary

*** Variables ***
${BROWSER}        headlesschrome

*** Test Cases ***
My Test
    Open Browser        https://www.duckduckgo.com  ${BROWSER} 
    Set Selenium Speed  1s
    Input Text          search_form_input_homepage  This is a test
    Click Button        search_button_homepage
    Sleep               5s
    Title Should Be     garbage to force failure for screenshot
    [Teardown]          Close Browser

*** Keywords ***

This should cause the web page to search for “This is a test”. However, only “Thi” makes it across to the web page (see attached screenshot).

We are running on Ubuntu 18.04 with the following:

$ apt list 2> /dev/null | grep google-chrome
google-chrome-beta/stable 76.0.3809.62-1 amd64
google-chrome-stable/stable,now 75.0.3770.100-1 amd64 [installed]
google-chrome-unstable/stable 77.0.3833.0-1 amd64
$ apt list 2> /dev/null | grep selenium
libtest-www-selenium-perl/bionic,bionic 1.36-2 all
python-selenium/bionic,bionic 3.8.0+dfsg1-3 all
python3-selenium/bionic,bionic 3.8.0+dfsg1-3 all
$ pip list 2> /dev/null | grep selenium
robotframework-selenium2library (3.0.0)
robotframework-seleniumlibrary (3.3.1)
selenium (3.141.0)

There are some rather baffling details:

• We see the identical symptom with both chrome and headlesschrome.
• The same robot under firefox works perfectly.
• We do not see the symptom (on any browser) if we are logged onto the system locally or if we use ssh+X11 forwarding to another Linux system.
• We do see the symptom consistently on Mac machines using ssh+X11 forwarding to XQuartz.

If the problem were with XQuartz, we would expect the same symptom regardless of browser. If the problem were with the chrome/headlesschrome drivers, we would expect the same symptom when the X server is on Linux. The fact that others have seen the same symptom (issue #1285) has us looking here first.

Any ideas?

chrome_issue.log

[reyelts]

I spent more time playing around with this. Using the simple login page to obviate login issues, I tried the following:

• I changed formelement.py so _input_text_into_text_field() sends one character at a time (and added trace records to prove it). That had no effect… I get the same result as sending the whole string at once.

• I tried changing “This is a test” to “tttt tt t tttt” (same string format… just all t’s). All of the t’s made it, but the spaces did not. It is almost as if something is seeing some of the characters as special.

• I switched the X server from XQuartz (Mac) with port forwarding over ssh to instead use xvfb locally on the Linux machine (where Robot Framework+SeleniumLibrary are running). Success.

Since GeckoDriver/Firefox doesn’t exhibit the symptom, it would appear the problem is with ChromeDriver. At least for my case, it simply doesn’t play well with the X Server (XQuartz) and port forwarding over ssh on Mac. I did some poking around on their bug tracking site and found this:

https://bugs.chromium.org/p/chromedriver/issues/detail?id=2859&q=xquartz&colspec=ID Status Pri Owner Summary

So, I’m going to follow that path and see where it goes.

@aaltat, thanks for your help and pointers.

[aaltat]

No problems, glad that I could assist you in to the right direction.