Protractor: Calling element.sendKeys() seems to not send all the keys
I am doing the following two tests:
it("Should be able to populate the firstname field", function () {
expect(capturePageModel.findFirstNameFieldValue()).toEqual("");
capturePageModel.setFirstNameFieldValue("Adam");
expect(capturePageModel.findFirstNameFieldValue()).toEqual("Adam");
});
it("Should be able to populate the lastname field", function () {
expect(capturePageModel.findLastNameField()).toEqual("");
capturePageModel.setLastNameFieldValue("Parrish");
expect(capturePageModel.findLastNameField()).toEqual("Parrish")
});
When I execute both tests in the same describe block I definitely am seeing the second test only send the "sh" value of the "Parrish" value I am passing in. Thus the test fails.
However each test runs fine by itself. I am attempting to use PageObjects to write a few documents on how this could work but curious if you have seen anything like this happen.
Simple example of my setter and getter functions in my PageObjects
this.setLastNameFieldValue = function( value ) {
var lastNameElement = element(by.model('presubmitUser.lastName'))
lastNameElement.sendKeys( value );
}
this.findLastNameField = function() {
var firstNameElement = element(by.id('lastName'))
return firstNameElement.getAttribute('value');
}
The first name field is identical to the last name field.
neosavvy
All 56 comments
Not sure what's going on here - could you share the test output?
juliemr
on 11 Apr 2014
Starting selenium standalone server...
Selenium standalone server started at http://192.168.1.16:59995/wd/hub
....F
Failures:
1) As a user I want to be able to register as a new candidate Should be able to populate the lastname field
Message:
Expected 'sh' to equal 'Parrish'.
Stacktrace:
Error: Failed expectation
at null.<anonymous> (/NEOSAVVY/src/<snip>/frontend/src/test/resources/integration/specs/register-new-candidate-spec.js:37:54)
Finished in 2.69 seconds
5 tests, 7 assertions, 1 failure
Notice that in the sendKeys test I am sending the text "Parrish" but the only value that makes it into the input is "sh" I was seeing that sometimes it would be "rrish" or "rish" which implies a race condition of sorts. I tried a few sleep() / wait() type approaches but it just didn't work.
neosavvy
on 11 Apr 2014
Huh, that's very strange - I've never seen something like this. I would guess that something funny is going on in the app - when they're in the same describe block, there's no page reload in between the tests?
The closest thing I can remember to seeing is we had an issue testing docs.angularjs.org where sendKeys wouldn't send anything after a '/'. It turned out that the search bar was stealing focus on '/', so this was actually a real bug with the page. Is it possible that something like that is going on?
juliemr
on 11 Apr 2014
I can definitely simplify my page there is quite a lot, we are attempting to save the data as a user types it. We have an ng-blur style directive that sends data on keypress. I would still expect to see the first keys get sent vs the last keys. You are probably right I'll dig more into what we are doing an eliminate variability on my page to be sure about this.
neosavvy
on 11 Apr 2014
I think I may be having the same issue: sendKeys() seems to be interpreting the letters e and r as control characters rather than regular characters:
var email = $('input#email');
// Sending 'e' or 'E' deletes the previous character
email.sendKeys('abcde'); // => Types 'abcd' then deletes the 'd'
email.sendKeys('ABCDE'); // => Types 'ABCD' then deletes the 'D'
// Sending 'r' moves the focus to the next input element
email.sendKeys('abcrabc'); // => Types 'abc' in the email input, switches focus to the password input, and types 'abc'
// Sending 'R' does nothing
email.sendKeys('ABCR'); // => Types 'ABC'
Here's a simple page I used to isolate the problem:
<!DOCTYPE html>
<html ng-app>
<head>
<title>Sign In</title>
<meta http-equiv="content-type" content="charset=UTF8"></meta>
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.0-beta.6/angular.min.js"></script>
</head>
<body>
<div id="main">
<form>
<div>
<input id="email" type="email" title="Email" placeholder="Email" required="" name="email"></input>
</div>
<div>
<input id="password" type="password" title="Password" placeholder="Password" name="password"></input>
</div>
<div>
<button type="submit">Sign In</button>
</div>
</form>
</div>
</body>
</html>
My system:
ubuntu 13.10
protractor 0.22.0
selenium-webdriver 2.41.0
chromedriver 2.9
chromium-browser 33.0.1750.152
ihough
on 23 Apr 2014
Interesting, I have the same setup but Mac and chrome Version 34.0.1847.116, and I don't see this crazy behavior. Let me try on a linux box.
juliemr
on 23 Apr 2014
Tried it on a Mac with chrome Version 34.0.1847.116 and it worked fine. I'm upgrading to Ubuntu 14.04 and will see if the issue persists.
ihough
on 24 Apr 2014
@ihough and @neosavvy I tried this a couple months ago and couldn't reproduce. Now that there have been a few updates to webdriver and protractor, can you try this again and let us know if this behavior is still happening?
hankduan
on 24 Jun 2014
@hankduan I think in my case the issue is actually a problem with X11 forwarding over ssh. My Ubuntu box is a headless vagrant machine based on chef/ubuntu-13.10. Here's my setup and test:
Ubuntu 13.10 (headless vagrant machine based on chef/ubuntu-13.10)
protractor 1.0.0-rc1
selenium-webdriver 2.42.1
chromedriver 2.10
chromium-browser 34.0.1847.116
describe('sendKeys()', function() {
browser.get('http://localhost:80');
var email = element(by.id('email'));
var password = element(by.id('password'));
beforeEach(function() {
email.clear();
password.clear();
});
it('should be able to type "abcde"', function() {
email.sendKeys('abcde');
expect(email.getAttribute('value')).toEqual('abcde');
expect(password.getAttribute('value')).toEqual('');
});
it('should be able to type "ABCDE"', function() {
email.sendKeys('ABCDE');
expect(email.getAttribute('value')).toEqual('ABCDE');
expect(password.getAttribute('value')).toEqual('');
});
it('should be able to type "abcrabc"', function() {
email.sendKeys('abcrabc');
expect(email.getAttribute('value')).toEqual('abcrabc');
expect(password.getAttribute('value')).toEqual('');
});
it('should be able to type "ABCRABC"', function() {
password.sendKeys('ABCRABC');
expect(password.getAttribute('value')).toEqual('ABCRABC');
expect(email.getAttribute('value')).toEqual('');
});
});
I can reproduce the issue if forward X11 over ssh to my local machine:
vagrant@vagrant:/vagrant$ node_modules/protractor/bin/protractor protractor-conf.js
Using ChromeDriver directly...
FFFF
Failures:
1) sendKeys() should be able to type "abcde"
Message:
Expected 'abc' to equal 'abcde'.
Stacktrace:
Error: Failed expectation
at null.<anonymous> (/vagrant/spec.js:14:41)
2) sendKeys() should be able to type "ABCDE"
Message:
Expected 'ABC' to equal 'ABCDE'.
Stacktrace:
Error: Failed expectation
at null.<anonymous> (/vagrant/spec.js:20:41)
3) sendKeys() should be able to type "abcrabc"
Message:
Expected 'abc' to equal 'abcrabc'.
Stacktrace:
Error: Failed expectation
at null.<anonymous> (/vagrant/spec.js:26:41)
4) sendKeys() should be able to type "abcrabc"
Message:
Expected 'abc' to equal ''.
Stacktrace:
Error: Failed expectation
at null.<anonymous> (/vagrant/spec.js:27:44)
5) sendKeys() should be able to type "ABCRABC"
Message:
Expected 'ABC' to equal 'ABCRABC'.
Stacktrace:
Error: Failed expectation
at null.<anonymous> (/vagrant/spec.js:32:44)
6) sendKeys() should be able to type "ABCRABC"
Message:
Expected 'ABC' to equal ''.
Stacktrace:
Error: Failed expectation
at null.<anonymous> (/vagrant/spec.js:33:41)
But the issue does _not_ occur if I use xvfb to run chromium-browser headlessly:
vagrant@vagrant:/vagrant$ export DISPLAY=:10 && Xvfb :10 -screen 0 1366x768x24 -ac &
[1] 2044
vagrant@vagrant:/vagrant$ node_modules/protractor/bin/protractor protractor-conf.js
Using ChromeDriver directly...
....
Finished in 8.108 seconds
4 tests, 8 assertions, 0 failures
This might be a problem between X11/webdriver (or some other aspect of X11) instead of protractor.
To test this (and since I dont' have this environment set up), can you try sending commands directly through webdriver instead of through the protractor logic.
i.e.
it('should be able to type "abcde"', function() {
var driver = protractor.getInstance();
var email = driver.findElement(by.id('email')); // This returns a raw WebElement from Webdriver
email.sendKeys('abcde');
email.getAttribute('value').then(function(value) { // This does not use the protractor "expect" wrapper
assert.equal(value, 'abcde');
});
});
@hankduan tried using unwrapped WebDriver and assertions -- all tests fail in the same way. Looks to me like this isn't an issue with Protractor.
ihough
on 30 Jun 2014
You might need to chase this up with X11 or webdriver.
Try showing them some code that is purely webdriver. See https://code.google.com/p/selenium/wiki/WebDriverJs.
hankduan
on 30 Jun 2014
Thanks
ihough
on 30 Jun 2014
Closing this issue as it's not a protractor issue.
hankduan
on 8 Aug 2014
Just stumbled upon this issue with the latest Protractor and SauceLabs. SauceLabs was receiving the correct instructions, i.e. set value to "The Dark Knight", but only "TheDark" (and sometimes even different character sequences) ended up in the text field, followed by a return instruction which resulted in a page navigation. You can even see this behavior in SauceLabs' recordings (see the last three screenshots) [1].
After fiddling around for quite some time I simply switched over to Firefox from Chrome and wasn't seeing any more issues. While this is not a general solution, it was sufficient for my workshop use case.
[1] https://saucelabs.com/tests/d86fcf7d99924643b20845a153c7d903
bripkens
on 4 Oct 2014
@bripkens Are you sure that's not your app doing it? It looks like "The Dark Knight" is sent (you can see it being typed in), but after you hit post, "TheDark" shows up.
I'm guessing your app is trimming the output to a specific length or something.
hankduan
on 6 Oct 2014
@hankduan It is actually not doing anything interesting with the input [1, 2]. Also, tests are working with Firefox on SauceLabs and locally too with the latest Chrome.
[1] https://github.com/codecentric/movie-database-node/blob/master/client/js/controller.js#L26-L32
[2] https://github.com/codecentric/movie-database-node/blob/master/client/partial/movies/_form.html#L10
bripkens
on 8 Oct 2014
Same problem here, my setup:
OS: MAC OS X 'Mavericks'
node -v: v0.10.29
npm -v: 1.4.16
At times, the input gets fully entered, at other times only one or two characters make it.
wayneseymour
on 9 Oct 2014
@bripkens Can you try to replace element(...).sendKeys("The Dark Knight"); to something purely webdriver to see if same behavior holds? Also, can you put a trimmed down version of your app/test/setup into its own repo for me to reproduce?
@wayneseymour Can you provide more information? i.e. browser (i.e. is it phantom), specs-code, app-code.
hankduan
on 9 Oct 2014
Sure.
Latest chrome.
protractor-1.2.0
Also in the page object pattern, but here is the gist of it:
return $('some css classes').sendKeys('some-text-with-hyphens-and-[brackets,and-a-comma]'); // promise chain
I don't think sending a string with hyphens, brackets, and commas will reproduce this on a general basis. Can you provide the app you're running against as well? (Unless you get this behavior sending that string to any angular app --i.e www.angularjs.org, by which case, definitely let me know as well)
hankduan
on 10 Oct 2014
haha, I wish I could send you a link.
But, its my company's proprietary app. You know how it goes.
I think there may just be a race condition I can pin down. I put in a sleep and that works...but that wont make it past code review! :)
wayneseymour
on 10 Oct 2014
@wayneseymour Let me know what you find. There has been a few reports of this issue, but no one thus far has been able to provide an example that allows me to reproduce yet
hankduan
on 10 Oct 2014
will do, thanks man!
wayneseymour
on 10 Oct 2014
+1 get this on a proprietary app via chromedriver/SauceLabs when entering '01234569789', and with subdivided portions of that string. Result is generally '0123' or similar, with the latter part of the string missing.
Local chromedriver works without fault. Will attempt to duplicate/trim code and get a failing test over.
sublimino
on 24 Oct 2014
Had the same issue. Somehow by calling element.clear() before element.sendKeys(), even if the input was initially empty, solved it for me.
kuiro5
on 24 Oct 2014
Innumerable permutations of sendKeys() failed, so I worked around the failing-on-Saucelabs issue like so:
var inputSelector = '.create-search-input';
browser.executeScript('window.jQuery("' + inputSelector + '").val("12345678A123456")');
browser.executeScript('angular.element(window.jQuery("' + inputSelector + '")).triggerHandler("input")');
Having similar issue with protractor v1.3.1 with Chrome (38.0.2) or Safari (7.0.5), resulting in timeouts, most likely its their bug, because Firefox and IE both work fine.
The test is quite simple:
browser.get('https://localhost/');
element(by.id('email')).sendKeys('a');
verbose mode shows log for Safari case:
16:01:56.385 INFO - Executing: [find elements: By.id: email])
16:01:56.579 INFO - Done: [find elements: By.id: email]
16:01:56.620 INFO - Executing: [send keys: 0 [[SafariDriver: safari on MAC (null)] -> id: email], [a]])
16:02:24.344 INFO - Executing: [delete session: 280366b7-a77a-4a98-8903-1482987925ff])
16:02:28.302 WARN - Exception thrown
org.openqa.selenium.TimeoutException: Timed out awaiting response to command "sendKeysToElement" after 30001 ms (WARNING: The server did not provide any stacktrace information)
Possible related issue: https://code.google.com/p/selenium/issues/detail?id=6537&q=safaridriver&sort=-summary&colspec=ID%20Stars%20Type%20Status%20Priority%20Milestone%20Owner%20Summary
With Chrome however, its much worse, because it not only doesn't affect the input, it doesn't close the browser (and even regular closing doesn't help, I have to use killall)
16:14:02.971 INFO - Executing: [find elements: By.id: email])
16:14:02.993 INFO - Done: [find elements: By.id: email]
16:14:03.031 INFO - Executing: [send keys: 0 [[ChromeDriver: chrome on MAC (b41eeee0117fb5c3cefa2505115eec09)] -> id: email], [a]])
16:14:25.765 INFO - Executing: [delete session: 8ce3e2be-efc2-4bb8-9970-b55754ded82b])
But executeScript() with jquery suggested by @sublimino works nicely, though that means I can't use native by.model selectors, which is a pity. But, i can emulate that with..
browser.executeScript('return $("input[ng-model=\'credentials.email\']").val("sdfwef");');
tot-ra
on 5 Nov 2014
Having issues with sendKeys() where 5 is being treated as a backspace and 6 just terminates the process of sending keys to the input all together.
Ex)
elem.sendKeys(58801) would yield 8801 in the input
elem.sendKeys(85801) would yield 801 in the input
elem.sendKeys(88601) would yield 88 in the input
However if I run it on Windows rather than Linux (via Sauce Labs) it works just fine. I think they keys are mapped differently for whatever version of Linux Sauce is using and that was my issue.
Aaron-Hartwig
on 30 Dec 2014
Yes can you check the mapping. This does not seem like a general issue.
hankduan
on 30 Dec 2014
I have this issue using chromedriver regardless of angular in use. phantomjs doesn't cause the same issues.
jdgiotta
on 10 Apr 2015
Having trouble with .sendKeys()
element.all(by.tagName('my-text')).get(0)
.element( by.tagName('div') )
.element( by.tagName('input') ).sendKeys("Hello");
It gives me
Message:
ElementNotVisibleError: element not visible
But if I do
expect( element.all(by.tagName('my-text')).get(0)
.element( by.tagName('div') )
.element( by.tagName('input') ).isPresent() ).toBeTruthy();
it passes the test
Any idea on why I can't sendKeys to the element??
Any help would be greatly appreciated, Thanks!
Haseeb90
on 16 Jun 2015
It might be present but not visible. Regardless, please ask that kind of question on Stack Overflow.
sjelin
on 16 Jun 2015
Workaround: set value using JS (simply execute $("#your-id").val("your-value"))
DenisGorbachev
on 14 Sep 2015
@DenisGorbachev So I am using the JavaScript above to set the input, but it appears that the (ng-model) binding is not picking up the change. Any idea how to force the change detection in Angular2?
mikeloll
on 17 Nov 2015
Might be related to https://bugs.chromium.org/p/chromedriver/issues/detail?id=1037
it happens on remote connections (e.g. using vnc)
holdfenytolvaj
on 22 Jan 2016
@DenisGorbachev your workaround with $("#your-id").val("your-value") doesn't seem to work anymore. It says .val is not a function. Is that correct? (using the latest protractor version)
pgrm
on 16 Feb 2016
another workaround: pass individual chars to sendKeys:
'blah'.split('').forEach((c) => element.sendKeys(c))
dodoshanti
on 23 Feb 2016
@dodoshanti thanks for the workaround! It slows a bit down the process but at least it works :)
foch
on 25 Feb 2016
@dodoshanti , @foch
The problem is happening because a previous test is using the modifier keys and the modifier keys are not released.
By Design the modifier (SHIFT, CONTROL, ALT, META) keys are stateful, and once they are pressed, they remain in pressed state unless
1) One of the modifier key is pressed again, or
2) webDriver.Key.NULL is passed
So the easiest solution is to use these keys like this
browser.actions()
.sendKeys(protractor.Key.ALT)
.sendKeys('s')
.sendKeys(protractor.Key.NULL) // Passing Null is extremely important
.perform();
Very well explained here: webdriver.WebElement.sendKeys
hiteshaneja
on 25 Feb 2016
@hiteshAneja thanks for the info. In our case we were not using any modifier keys
dodoshanti
on 2 Mar 2016
I'm still getting this issue. Are there plans to fix this?
@wayneseymour Did you ever find a fix?
@pgrm I think you're supposed to execute that within the browser context
@dodoshanti that is pretty ghetto, but it works
moneytree-doug
on 19 Apr 2016
@pgrm I think you're supposed to execute that within the browser context
moneytree-doug
on 19 Apr 2016
same issue,sendkeys typing first character only.
using mocha 2.4.5 in windows 8.1
var emailTxt = driver.findElement(webdriver.By.name('Email'));
driver.wait(emailTxt,10000);
emailTxt.sendKeys("testing");
aniljogireddy
on 7 May 2016
Hi, I am encountering the same issue as described in this post:
Aaron-Hartwig commented on Dec 30, 2014
Having issues with sendKeys() where 5 is being treated as a backspace and 6 just terminates the process of sending keys to the input all together. Ex)
elem.sendKeys(58801) would yield 8801 in the input
elem.sendKeys(85801) would yield 801 in the input
elem.sendKeys(88601) would yield 88 in the input
This is only happening when I run the tests from Jenkins, and does not occur when running on my local machine. What is a possible solution to this? Could it be something related to the Locale settings?
dwaned
on 30 May 2016
We also only have this issue on jenkins and not locally...
svetozar02
on 1 Jun 2016
I'm seeing this issue with the Microsoft Web driver (v 10586) on Edge - exactly the same test passes using Chrome driver. Windows 10 machine, Protractor Javascript.
For example, if I sendKeys("ABCDEFGHIJ") to an input text box, only some of the chars appear.
Ragnaar
on 23 Aug 2016
Still exists.
Site:
http://maxcabrera.com/code/todo-list/
Protractor - 4.0.10
[15:53:15] I/status - selenium standalone version available: 2.53.1 [default]
[15:53:15] I/status - chromedriver version available: 2.25 [default]
[15:53:15] I/status - geckodriver version available: v0.11.1 [default]
[15:53:15] I/status - android-sdk is not present
[15:53:15] I/status - appium is not present
NodeJS - 7
Test:
it('should create new note', function () {
browser.get(URL)
let webelement = $('input.enter-todo')
webelement.clear()
webelement.sendKeys('HHHHHHHHHHHHHHH')
browser.sleep(2000)
webelement.submit()
let notes = $$('todo-list .small-12')
browser.sleep(2000)
//expect(notes.getText()).not.toContain('New Shiny note')
expect(notes.getText()).toContain('HHHHHHHHHHHHHHH')
})
Xotabu4
on 11 Nov 2016
I think that the issue might be related to keyup / keydown triggers.
I got around the issue by introducing a helper function with a tiny delay after each character:
function controlledInsert( elm, txt, delay ) {
for (var i = 0, len = txt.length; i < len; i++) {
elm.sendKeys( txt[ i ] );
browser.driver.sleep( delay );
}
elm.sendKeys(protractor.Key.NULL);
}
jlstrat
on 6 Feb 2017
I am also facing the same issue while testing mobile App but strange thing is that it is working on other pages correctly only on particular page it is behaving differently.
richashri87
on 10 Mar 2017
Found similar kind of issue when I upgraded my chrome to v57
prudvinath6
on 16 Mar 2017
I discovered keys like "@" and "." are not sent. Switching browser from Chrome to Firefox fixes the issue.
This seems not related though, as alphanumerical input is still sent properly (string lenght does not matter).
Phoscur
on 25 Mar 2017
If it's helpful to others coming across this, I had this problem where sendKeys would consistently skip some characters. An ng-change that I have on the element that updates another element's value on the page (but does not change focus) caused the issue. Removing that ng-change fixed it. I need the ng-change so I used @dodoshanti 's 'blah'.split('').forEach((c) => element.sendKeys(c)) which fixed it for me (likely should actually do a .then if possible after each sendKeys(char) to make sure but works for me w/o it).
tonybranfort
on 16 Jun 2017
Even I was facing the same problem. What i changed was instaed of using sendkeys i used setvalue.
Setvalue will be active when you use android element instead of web or mobile elemnt
palak1234
on 28 Jun 2017
@kuiro5 thanks a ton your solution work for me :D
Jayesh-raweng
on 6 Sep 2017
I have a text with . and @ I have to split them up
lay.mui.[email protected]
await driver.elementByAccessibilityId('textUserName').sendKeys('[email protected]')
textfield will show laymui.[email protected]
I have to split them up in the code like this:
await driver.elementByAccessibilityId('textUserName').sendKeys('lay');
await driver.elementByAccessibilityId('textUserName').sendKeys('.mui');
await driver.elementByAccessibilityId('textUserName').sendKeys('[email protected]');
also I am not able to clear the textfield
any one has any idea how I can clear the textfieldawait driver.elementByAccessibilityId('textUserName').clear() didn't work for me
LayMuiToh
on 25 Oct 2018
Related issues
adityagautam
路
3Comments
koshkarov
路
3Comments
smarts
路
3Comments
premkh9
路
3Comments
vdrulerz
路
3Comments
Most helpful comment
another workaround: pass individual chars to sendKeys:
'blah'.split('').forEach((c) => element.sendKeys(c))