Selenium: IE Driver shift key confusion

[kirk-clover]

🐛 Bug Report

A string sent to a text input field will have the numbers or characters that are typed while holding shift and a number are transposed. For example [email protected] becomes test2example.com and [email protected] becomes member!)!*^@example.com

This only appears to happen when I attempt to enter text into the username field on a log-in screen at the beginning of my tests.

To Reproduce

Cannot consistently reproduce. I'll update here if I get the OK to share video of the test.

Expected behavior

The string sent via sendKeys should be reflected accurately in the input field

Test script or set of commands reproducing this issue

Environment

OS: Windows 10
Browser: IE
Browser version: 11.0
Browser Driver version: IE Driver 3.9.0
BrowserStack: 7.2

[jimevans]

There is not enough information to begin looking at this issue. First, the version of the IE driver you’re using (3.9.0) is several versions old; the latest is 3.141.5.

Second, you’re giving no indication of the settings or capabilities you’re using to launch the browser. Use of the requireWindowFocus or useNativeEvents capabilities can drastically change how keystrokes are simulated.

[kirk-clover]

Sorry if I left out helpful info. I'm still relatively new to Selenium, so I do apologize.

I just took a look at the settings & logs:
nativeEvents: true
requireWindowFocus: false

Here's a snippet from the selenium log showing that the email address is intact:

13:18:52.028 INFO [14] org.openqa.selenium.remote.server.DriverServlet - Executing: [send keys: 0 [[InternetExplorerDriver: internet explorer on WINDOWS (06f066c4-45d5-42c4-87ba-81c3cc04e77e)] -> css selector: input[name="username"]], [t, e, s, t, @, e, x, a, m, p, l, e, ., c, o, m]])
13:18:52.029 DEBUG [78] org.openqa.selenium.remote.RemoteWebDriver - Executing: sendKeysToElement [06f066c4-45d5-42c4-87ba-81c3cc04e77e, sendKeysToElement {id=4dc6b187-b667-4923-a22b-9fda9e3df384, value=[Ljava.lang.String;@f9723b}]

Then a bit further down:

13:18:53.000 DEBUG [78] org.openqa.selenium.remote.RemoteWebDriver - Executed: [06f066c4-45d5-42c4-87ba-81c3cc04e77e, sendKeysToElement {id=4dc6b187-b667-4923-a22b-9fda9e3df384, value=[Ljava.lang.String;@f9723b}]
13:18:53.000 INFO [14] org.openqa.selenium.remote.server.DriverServlet - Done: [send keys: 0 [[InternetExplorerDriver: internet explorer on WINDOWS (06f066c4-45d5-42c4-87ba-81c3cc04e77e)] -> css selector: input[name="username"]], [t, e, s, t, @, e, x, a, m, p, l, e, ., c, o, m]]

I'm happy to provide more information.

As a work around, after initially setting the username, we're clearing the element then setting it again. That seems to always work.

[jimevans]

So, again, you’ll really need to update to the latest driver (3.141.5). Also, if that doesn’t work by itself, please try setting requireWindowFocus to true and see if that changes anything.

[kirk-clover]

BrowserStack just updated the IE driver option to 3.141.5. As you suggested, I'll try that first.

[kirk-clover]

We've bumped the version to 3.141.5 in our CI environment. I'll monitor and report back after a few days.

[kirk-clover]

I'm still seeing the mistyped letters in the first input field. I'll try setting requireWindowFocus to true and report back.

[kirk-clover]

We were unable to get stop happening. As a work around, we decided to isolate any characters that involve the shift key in their own sendKeys call. So, instead of sending "[email protected]" in one call, we're sending it using three calls: "test", "@", "example.com"

[sercegovic]

Solution mentioned above just partially solved basically the same issue we had, so just in case someone is still having this kind of problems...
We added another workaround:
def type_keys(self, value):
for key in value:
self.send_keys(key)
sleep(0.01)

With self.capabilities["browserstack.selenium_version"] = "3.14.0"

[lviana-menlosecurity]

We test with all 5 major browsers (Chrome, Edge, IE, FF, Safari), and I definitely see the the same shift key problem with IE only. Granted, this only happens a small percentage of the time, maybe 1-5 out of every 1,000 tests, while entering the password to login. Definitely seems like a bug with the IEDriver.