sendKeys drops first character

[BillR]

With 2.19/FF7 and now 2.22/FF12 on W7 I'm seeing the 1st char get
dropped from an input area, or sometimes a leading '4' morphs into
'$'. Here's some retry code that doesn't always succeed:

<input class="sendAmtFld" type="text" id="sendAmount" maxlength="7"
value="200.00" autocomplete="off">

String s = Double.toString(sendAmount);
for (int i=0; i<5; i++) {
sendAmountField.clear();
sleep(i * 100);
sendAmountField.sendKeys(s);
String ss = getSendAmount();
if (s.equals(ss)) {
return true;
}
System.out.println("Wrong sendAmount: [" + ss + "]
tried " + s);
}
// one more try
sendAmountField.clear();
for (int i=0; i<s.length(); i++) {
String ss = "" + s.charAt(i);
sendAmountField.sendKeys(ss);
}
String ss = getSendAmount();
if (s.equals(ss)) {
value = sendAmount;
timesSet++;
return true;
}
System.out.println("Wrong sendAmount/final: [" + ss + "]
tried " + s + " js error: " + getJSError());

Here are some cases where retry was done:

[INFO] Wrong sendAmount: [75.0] tried 275.0
[INFO] Wrong sendAmount: [50.0] tried 350.0
[INFO] Wrong sendAmount: [$00.0] tried 400.0 <<< morphed '4'
[INFO] Wrong sendAmount: [624.99] tried 2624.99
[INFO] Wrong sendAmount: [624.99] tried 2624.99
[INFO] Wrong sendAmount: [624.99] tried 2624.99
[INFO] Wrong sendAmount: [775.0] tried 2775.0
[INFO] Wrong sendAmount: [850.0] tried 2850.0

And here's a case where all retries failed:

[INFO] Wrong sendAmount: [400.0] tried 1400.0
[INFO] Wrong sendAmount: [400.0] tried 1400.0
[INFO] Wrong sendAmount: [400.0] tried 1400.0
[INFO] Wrong sendAmount: [400.0] tried 1400.0
[INFO] Wrong sendAmount: [400.0] tried 1400.0
[INFO] Wrong sendAmount/final: [40] tried 1400.0 js error: null

This kind of reduces an automated test to a manual one, in which
screenshots always need to be examined and tests rerun. Is this
normal?

Thanks,
Bill

[BillR]

Based on the lack of response here, and feedback from another QA team
we happened to meet with yesterday, it seems reliable webdriver tests
are more the exception than the rule, and webdriver tests are better
viewed as a start for a manual test/verify cycle, at least where
javascript use is significant.

Another case I have been dealing with involves js marking a field as
class='emphasis loading' (adding 'loading' then removing it) when it
is calculating: text gets greyed out until the value is calculated.
Once every now and then it gets stuck in this state for, say, 20
minutes - garbage collecting? It doesn't look like there's a way to
force garbage collection in FF. So I have to decide whether to
interrupt the test to pop a new browser, or wait however long it
needs. Plus it would be a good idea to review the js, since on the
order of 100 value entries (with calc of 5 derived values) seems a bit
early for garbage collection to kick in.

Here is the page I'm testing btw:

https://www.xoom.com/colombia/fees

[darrell]

Bill,

Your logic is flawed. A lack of response here means that people are
busy doing other things. NUMEROUS times I have pointed out to people
that if you post a request for help and there is insufficient
information, the people capable of helping you will skip over your
posting until they have more time available to them. If I'm running a
quick test and have 2 minutes to spare, I'll pop in here and answer a
few questions. If I have to think about what you have posted, figure
out what information is missing and request it from you, I'll wait
until I've completed my current task, at the job I'm PAID to do before
I take time to give FREE help.

You have a call to getSendAmount() which you have not provided the
code. I suspect whatever you are doing in getSendAmount() or in code
you have not included in this code snippet is the problem.

Since you gave the website you are attempting to automate and the
output you received (from code you did not actually post) I was able
to produce:

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;

public class Test {

public static void main(String[] args) {
double d[] = { 275.0, 350.0, 400.0, 2624.99, 2624.99, 2624.99,
2775.0, 2850.0 };
WebDriver driver = new FirefoxDriver();
driver.get("https://www.xoom.com/colombia/fees");
for(int i = 0; i < d.length; i++) {
double sendAmount = d[i];
String s = Double.toString(sendAmount);
WebElement we = driver.findElement(By.id("sendAmount"));
we.clear();
try { Thread.sleep(i * 100); } catch (Exception e) { }
we.sendKeys(s);
String ss = we.getAttribute("value");
if(s.equals(ss)) {
System.out.printf("Match: Got %s, expected %s.\n", ss, s);
} else {
System.out.printf("Wrong: Got %s, expected %s.\n", ss, s);
}
}
driver.close();
}
}

The output for this on Windows 7 with Firefox 12 was:

Match: Got 275.0, expected 275.0.
Match: Got 350.0, expected 350.0.
Match: Got 400.0, expected 400.0.
Match: Got 2624.99, expected 2624.99.
Match: Got 2624.99, expected 2624.99.
Match: Got 2624.99, expected 2624.99.
Match: Got 2775.0, expected 2775.0.
Match: Got 2850.0, expected 2850.0.

If you can post a code snippet which someone can take and run from
their system, we should be able to tell you what you are doing wrong.

Darrell

[Ross Patterson]

Bill's comment that "sometimes a leading '4' morphs into '$'" speaks volumes. That would happen if the SHIFT key was being inadvertently pressed by WebElement.sendKeys(), or by something calling it.

Ross

[BillR]

Thanks Darrell,

Here is the missing code:

public String getSendAmount() {
return sendAmountField.getAttribute("value");
}

No surprises there. It's an intermittent error. From what Ross said,
it sounds like it could be due to keyboard interference, e.g. now I
see if I hold the Shift key down while it's running, I get

[INFO] Wrong sendAmount: [998.99] tried 2998.99
[INFO] Wrong sendAmount: [998.99] tried 2998.99
[INFO] Wrong sendAmount: [998.99] tried 2998.99

Interestingly it doesn't happen if focus is on the browser, only if
the focus is on another window.

Bill

[BillR]

Thanks Ross,

Great catch. It seems like SHIFT can bleed from another application to
webdriver/FF on Windows at least. I see it happening with both another
instance of FF (where I'm typing this) and a cygwin terminal.

Bill

[darrell]

Well it is obviously not the code for getSendAmount() which is at
issue. There is still other code which is missing. How did you
initialize the sendAmountField variable? What datatype is it (I'm
assuming it is WebElement)? How did you open the web page? I.e. are
you using FirefoxDriver or RemoteWebDriver? Did you try running the
code I posted? Does that fail for you as well?

If the code I posted fails for you, there is something else in your
environment which is causing the problem. You need to focus on that
fact. If the code I posted works fine in your environment then it is
probably something else in your code which is causing the issue.

Darrell

[BillR]

As Ross indicated and I described, hitting the SHIFT key in other
windows causes dropped characters in the sendAmount field - probably
because all number+shift chars in the field are screened out by
javascript.

The take-home for webdriver developers for Windows is that the
physical shift key, used in other windows, affects what the webdriver
browser sees. I have found that by running on a test-only machine, few
if any such problems arise.

Bill

[Ross Patterson]

That sure sounds like a bug to me. I suggest you report it at https://code.google.com/p/selenium/issues/entry.

Ross

-----Original Message-----
From: webd...@googlegroups.com [mailto:webd...@googlegroups.com] On Behalf Of BillR
Sent: Tuesday, June 12, 2012 7:35 PM
To: webdriver
Subject: [webdriver] Re: sendKeys drops first character

...

[darrell]

Ah, this makes sense. Still seems odd that it is always the first
character which is getting affected.

I always set up a virtual machine (VM) to run my automation on. This
has a few advantages. First, you don't have to worry about mouse and
keyboard conflicts. Second, if your company has a group policy which
forces locking the system after XX minutes of inactivity, it will not
stop your automation from running properly in the VM. Third, easy to
switch from this sort of development environment to a distributed
build or grid deployment environment.

Darrell

[Simon Stewart]

It'll be any character which needs the shift key. It's a known problem
with the native events on Windows: the physical state of the keyboard
bleeds through to the tests when you're using the firefox and IE
drivers. Chrome and Opera are stable and not affected.

As for the stability of tests: I've seen lots of teams have completely
stable test runs using webdriver and selenium. It takes work to get
there, because it's waaaay too easy to blame test failures on the tool
rather than the app. Common problems I see are a failure to understand
the root causes of "ElementNotFoundException" and
"StaleElementReferenceExceptions" (which are almost _never_ webdriver
failing to work properly) and accidentally DOSing the AUT.

Simon

> --
> You received this message because you are subscribed to the Google Groups "webdriver" group.
> To post to this group, send email to webd...@googlegroups.com.
> To unsubscribe from this group, send email to webdriver+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/webdriver?hl=en.
>

[Bill Ross]

Interesting point. (It can be >1 char, but always leading.)
Maybe it is because sendKeys() manages to send the whole string
atomically, so there is no chance to get the shift key down in
the middle.

Bill

[Darren Rowley]

If you need to type in other windows while running tests you can switch off native events, for firefox you do this in the profile:

 firefoxProfile.setEnableNativeEvents(false);

This problem should go away now.

[Catherine Bartlett]

This post is a year old but i found it quite helpful so i want to post the code that worked for me to get around this. For me the problem showed up randomly in a test that had been running perfectly for days (no change on website) on firefox/ubuntu, firefox/windowsVista, and ie/windowsVista, so i assume it broke as the result of some change that had to do physically with my computer.

        # i replaced this line
        driver.find_element_by_id("theTextBox").send_keys("987654321")
        # with these three lines
        my_text_field = testUtilities.go_to_element_with_id(self, "theTextBox")
        my_text_field.click()
        my_text_field.send_keys("987654321")
        #  


Here's the go_to_element method_with_id method from testUtilities
(Remember to import ActionChains and WebDriverWait)

        def go_to_element_with_id(atest, element_id):
            tempElement = wait_for_element_with_id(atest, element_id)
            achain = ActionChains(atest.driver)
            achain.move_to_element(tempElement).perform()
            return tempElement

        def wait_for_element_with_id(atest, element_id):     
            WebDriverWait(atest.driver, 10).until(lambda driver: atest.driver.find_element_by_id(element_id).is_displayed())
            return atest.driver.find_element_by_id(element_id)

[RobbyM]

I realize this post is quite belated, but I found this topic when researching why sendKeys("...+i...") to IE11 would sometimes result in the input getting the value "...+I...", where a lowercase character following an character that requires the shift-key to be pressed would be entered as the uppercase character instead.

What I discovered is that the default behavior of the IEDriverServer.exe is to send keyboard input using SendMessage/PostMessage, which is apparently unreliable, especially related to modifier key state: https://blogs.msdn.microsoft.com/oldnewthing/20050530-11/?p=35513

Instead, http://jimevansmusic.blogspot.com/2013/01/revisiting-native-events-in-ie-driver.html describes that you can either:

 1. Opt-in to JavaScript-simulated events, by setting "nativeEvents" capability to false (see the blogpost for implications), or

 2. Force Selenium to use the more reliable SendInput method, by setting the "requireWindowFocus" capability to true (which will cause the IE driver to try to force the window to gain focus).

Each of these options comes with known (and possibly unknown) tradeoffs, but it seems that either should be able to send keyboard input more reliably.