Cypress: Cypress Doesn't Finish Typing Strings Before Continuing to Next Field
Current behavior:
When typing a long string into an input field, such as an email address to login in our case, Cypress 3.5.0 appears to no longer type the entire string. It bails on typing the complete string after the period in the email and never completely types the string. For example, [email protected] would be typed as test@webdomainhere. in our app, failing the login.
I have also seen similar things with usernames using mixed case, such as associateEnabled would be typed as associate, stopping before the capital letter in the string.
Due to this bug we have had to roll back to using Cypress 3.4.1, where this worked fine.
Example screenshot showing a failed login in Cypress 3.5.0 where the email should've had 'com' typed after the period:
Desired behavior:
Entire string passed to a cy.type() function should be typed into the input field.
Steps to reproduce: (app code and test code)
Type a long string, such as a long email address into a form field and then move on to a password field with a .click() and see that the end of the first string isn't entered.
Versions
Cypress v3.5.0 (v3.4.1 works fine, we have had to roll back)
Mac OSX 10.14.6
Electron 61 / Chrome 78
TheWanderingWalnut
All 109 comments
@TheWanderingWalnut Thanks for the report. are you using any frameworks? any component libraries? any custom javascript listening to keyboard events? sometimes there are edge cases we miss. In vanilla javascript, we have tests around this scenario and they passed.
Bkucera
on 26 Oct 2019
Unfortunately we have to close this issue as there is not enough information to reproduce the problem. This does not mean that your issue is not happening - it just means that we do not have a path to move forward.
Please comment in this issue with a reproducible example and we will reopen the issue. 🙏
jennifer-shehane
on 28 Oct 2019
@jennifer-shehane , I am unsure what you're looking for. Simply use cy.type() on an input field with a string with mixed case and it will reproduce the problem. This happens on various login screens around our app which I cannot share as they are proprietary. Please let me know what you're expecting for this bug to be investigated
TheWanderingWalnut
on 28 Oct 2019
Simply use cy.type() on an input field with a string with mixed case and it will reproduce the problem
Recreating what you said does not reproduce the problem. There are likely other variables involved with the input or your test that we cannot isolate without you providing a completely reproducible example.
Index.html
<!doctype html>
<html lang="en">
<body>
<input id="my-input">
</body>
</html>
Spec.js
it('works', () => {
cy.visit("index.html")
cy.get('#my-input').type('cAmElCaSe')
.should('have.value', 'cAmElCaSe')
})
Please provide a fully reproducible example so that we can fix your issue as quickly as possible. Thanks!
jennifer-shehane
on 28 Oct 2019
@bkucera , Sorry, I missed your comment on my first glance. I do not believe we have anything particular on any of those fields, though I have setup a quick example repo with help from our devs and found that using the fields on that page it's fine, so I presume it's something we're doing on that page.
I'll work on this again likely this afternoon, but will have to take some time to work on other issues in the meanwhile. I'll update this issue with anything further I find.
TheWanderingWalnut
on 28 Oct 2019
@jennifer-shehane Thank you for confirming you actually tested this. Had you confirmed you tested this in your first comment I wouldn't have worried about it. I've seen in the past when reporting bugs it's common to simply reject them, which I presumed from your previous comment's wording was what you'd done.
TheWanderingWalnut
on 28 Oct 2019
@TheWanderingWalnut as a workaround, you may want to just set the values with cy.get(...).invoke('val', '[email protected]'). If you can get us a reproducible I'll be happy to look more into this. Thanks!
Bkucera
on 29 Oct 2019
@Bkucera @jennifer-shehane I have not been able to reproduce this outside our app, though I can provide you below a public-facing internal test site which you can run a test against to see the bug.
The URL to use is https://cypressprodtesting.checkfront.com/ with the below code run against the provided page will fail in Cypress 3.5.0, while it will succeed in Cypress 3.4.1:
cy.get('#cf_id').click().type(partnerAccountActive);
cy.get('#cf_pw').click().type(partnerAccountActive);
cy.get('#cf_id').should('have.value', 'partnerAccountActive');
cy.get('#cf_pw').should('have.value', 'partnerAccountActive');
@Bkucera Thank you for the workaround, this is working for the time being, although there are other bugs in 3.5.0 which we need fixed before we can fully upgrade.
TheWanderingWalnut
on 31 Oct 2019
@TheWanderingWalnut I was not able to reproduce any failure in the provided test case in 3.4.1 or 3.5.0.
I did replace partnerAccountActive with a string 'partnerAccountActive' and added a visit. This is passing for me in both versions.
it('types in both fields', () => {
cy.visit('https://cypressprodtesting.checkfront.com/')
cy.get('#cf_id').click().type('partnerAccountActive')
cy.get('#cf_pw').click().type('partnerAccountActive')
cy.get('#cf_id').should('have.value', 'partnerAccountActive')
cy.get('#cf_pw').should('have.value', 'partnerAccountActive')
})
Maybe there is some other variable I am missing. I tried in Canary 80, Chrome 78, Chromium 74 and Electron 73 on my osMac Mohave machine using `cypress open.
Please also try updating to our recently released 3.6.0, since it fixed some type bugs that were introduced in 3.5.
jennifer-shehane
on 31 Oct 2019
@jennifer-shehane Hmmm, okay, it's still failing for me on 3.5.0 and 3.6.0 (sidenote, when did this come out? It isn't even in Cypress' changelog?). The only thing I can think of that might be different is in our app we have the Cypress BaseURL set to cypressprodtesting.checkfront.com, and then have a cy.visit('/'); at the top of our spec, then call the above code.
Sometimes I do have to run it a couple times, and other string which fail quite commonly include '[email protected]' as the username with whatever as a password.
Sorry, my bad, those were intended to be strings, that matches how we're using the code locally.
TheWanderingWalnut
on 31 Oct 2019
@jennifer-shehane @Bkucera Could one or both of you please try reproducing this with the below repo? I made a repo with just Cypress in it with a simple test which is failing probably 40-60% of the time I run it. Please run this test at least ten times to ensure it will fail once.
https://github.com/TheWanderingWalnut/cypressRunningAgainstProductionCF
Note that in this test the login will ALWAYS FAIL. This is just to demonstrate how Cypress v3.5.0+ will fail to type into the fields correctly. It appears to be rushing through and typing the last part of the username into the password field, which is causing test failures in CI for us.
Thank you!
TheWanderingWalnut
on 31 Oct 2019
I can confirm this reproduces the issue. It seems to take a few tries but for me, after 3-5 successful attempts it only types the first 2 or 3 letters. It seems to fail a lot more after that happens. Hitting Stop from the TR and rerunning it almost always succeeds the first couple of runs.
I was able to comment out everything reducing to just:
cy.get('#cf_id').type('partnerActive')
And still reproduce it. @jennifer-shehane can we reopen this?
oak-wildwood
on 1 Nov 2019
Have confirmed, this fails occasionally, especially after rerun in 3.6.0 in both Chrome and Electron.
This is irrespective of any characters being capitalized.
it("Logs in as a partner", () => {
cy.visit("http://cypressprodtesting.checkfront.com")
cy.get('#cf_id').type('partner')
.should('have.value', 'partner')
})
3.4.1
Passes on multiple reruns
3.5.0
Fails when rerunning the spec file. Also fails in 3.6.0
Events table indicates that it typed the full word 'partner', even though it only typed 'pa' into the email input and seemed to type the rest into the password field.
jennifer-shehane
on 4 Nov 2019
I'm running 3.4.1 with the following deps, and see this occuring intermittently on multiple fields, often missing the @ in emails, or dropping a digit off in a phone number field (we see it mostly in chrome, but also in electron too)
"@cypress/browserify-preprocessor": "^2.1.1",
"@slack/client": "^5.0.2",
"@types/cypress-axe": "^0.4.0",
"@types/node": "^12.7.8",
"aws-sdk": "^2.511.0",
"axe-core": "^3.3.1",
"browserify": "^16.5.0",
"cypress": "3.4.1",
"cypress-axe": "^0.5.1",
"cypress-failed-log": "^2.5.1",
"cypress-multi-reporters": "^1.2.1",
"cypress-slack-reporter": "^0.5.0",
"husky": "^3.0.3",
"lint-staged": "^9.2.1",
"mocha": "^6.2.0",
"mocha-junit-reporter": "^1.23.1",
"mochawesome": "^4.1.0",
"mochawesome-merge": "^2.0.1",
"mochawesome-report-generator": "^4.0.1",
"moment": "^2.24.0",
"prettier": "^1.18.2",
"shelljs": "^0.8.3",
"sonarqube-scanner": "^2.5.0",
"tsify": "^4.0.1",
"tslint": "^5.18.0",
"tslint-config-prettier": "^1.18.0",
"tslint-no-focused-test": "^0.5.0",
"typescript": "^3.5.3",
"uuid": "^3.3.2",
"xlsx": "^0.15.1"
Code for the fields as follows, everything written in typescript and uses browserify preprocessor
public populateContactDetails({
emailAddress,
phoneNumber
}: ContactDetailsOverridableFields = {}) {
cy.get(dataTestId("contactDetails_emailAddress"))
.should("be.visible")
.type(emailAddress || "[email protected]");
cy.get(dataTestId("contactDetails_phoneNumber"))
.should("be.visible")
.type(phoneNumber || "0700000000");
}
When it does error, I can see that cypress has attempted to type the full string, but the value appears to be missing one of the characters typed in
YOU54F
on 11 Nov 2019
@YOU54F can you check the events table that gets logged in the console if you click on the .type command, and post a screenshot of it here? I have seen cases where the input/textarea gets blurred during the type, and that should be represented by the table.
Bkucera
on 12 Nov 2019
@jennifer-shehane when we could expect to get it to fix?
Akshaya2312
on 28 Nov 2019
@Akshaya2312 We are no longer able to reproduce this behavior in our latest release since the example site that was provided to test against has changed.
Unfortunately we'll have to close this issue if no reproducible example is provided. Can anyone provide a way to reproduce this in 3.8.0?
jennifer-shehane
on 19 Dec 2019
Hello @jennifer-shehane,
Thank you for updating this ticket, although I wish you had informed me of the problems you had run into, rather than others who comment without examples. I have updated the example I provided, please look into this as soon as possible. If you run into any further problems, please let me know immediately so we can get this bug finally fixed.
Thank you,
TheWanderingWalnut
TheWanderingWalnut
on 19 Dec 2019
I see that you have updated the repo to the changes made on the public facing application so that we can now run the tests - this is the piece that was missing. Thanks for providing this.
We close issues because, as you can see, issues pile up with no path forward. We are always open to reopen issues when a new reproducible example is produced, so don't be alarmed. This is just our process.
I ran the code below and it is not failing to type the correct values into the inputs for me in 3.5.0, 3.7.0, 3.8.0 in Chrome 79, Chrome 74, or Electron, nor failing for the 20 times I reran the code in each situation.
Can you please paste a video of what is failing to type for you? And also ensure you are using version 3.8.0 of Cypress. If we are given a failing example - we will reopen this issue.
it("Types correctly into fields", () => {
cy.visit("http://cypressprodtesting.checkfront.com")
cy.get("#email")
.click()
.type("partnerActive")
.should("have.value", 'partnerActive')
cy.get("#password")
.click()
.type("partnerActive")
.should("have.value", 'partnerActive')
})
jennifer-shehane
on 20 Dec 2019
I also have same problem. has this solved? I am using invoke instead
sharpboy2008
on 22 Dec 2019
i am using 3.8.0. still have same issue. i am using invoke instead. could you pls look into it?and see if it can be fixed.
sharpboy2008
on 22 Dec 2019
@sharpboy2008 Please provide a reproducible example - HTML & test code to run. We do not currently have an example to reproduce this bug, so this is not fixed / no work has been done on this issue and cannot fix until that is provided using 3.8.0.
jennifer-shehane
on 24 Dec 2019
@jennifer-shehane Here is sample .not always can be produciable. but when trying many times ,it would appear.
cy.visit('https://law.wkinfo.com.cn/')
cy.contains('登录').click()
cy.get('#login-username').type('XXTEXXY.xxlpnc').should("have.value", 'XXTEXXY.xxlpnc')
cy.get('#login-password').type('wqswweewres88').should("have.value", 'wqswweewres88')
username and password can be any.chrome version 79.0.3945.88
sharpboy2008
on 24 Dec 2019
sharpboy2008
on 24 Dec 2019
sharpboy2008
on 24 Dec 2019
sometimes, it always '';
sharpboy2008
on 24 Dec 2019
Having the same problem after upgrading from 3.3.0 to 3.8.1. Test was not changed.
I have a failing rate of about 30%. Curently haven't more information. I'm still investigating.
mkickmaier
on 2 Jan 2020
I have the same problem. When I try to enter a random sequence of numbers starting with zero, it only enters zero (first character). It works on 3.4.1 but on 3.8.0 it fails. Keyboard event object contains full text.
pawelrudnicki
on 4 Jan 2020
We are having the same issue when using
cy.get('#some-input').clear().type('\\\\machinename.domain.local\\C:\\folder\subfolder');
Cypress stops typing after 'C:\'
Edit:
Ok nevermind, we found out that this was caused by an exception in our code thrown in the background during typing.
LoaderB0T
on 7 Jan 2020
I am facing the same problem. The failing rate is around 40%.
Code:
cy.get('#currency').type('241 14001 45191');
cy.get('#currency').invoke('val').should('contain', 'DK 241 14001 45191');
I am seeing in the logs that, sometime the typed value is missing '0' (typed value: 241 1401 45191) and some time its missing '1' (typed value: 24 1401 45191) .
DreamCreater
on 8 Jan 2020
@sharpboy2008 I can recreate your issue as described in 3.8.1 and it does look to be the same issue as the original one being opened.
I cannot recreate this issue in 3.7.0 actually - the test always passes. This makes me think this is slightly different in some way from the original issue.
Sometimes only a few characters are typed, sometimes no characters - it changes depending on reload of tests (ctrl+r).
Test code
it('types - char', () => {
cy.visit('https://law.wkinfo.com.cn/')
cy.contains('Login').click()
cy.get('#login-username').type('XXTEXXY.xxlpnc').should("have.value", 'XXTEXXY.xxlpnc')
cy.get('#login-password').type('wqswweewres88').should("have.value", 'wqswweewres88')
})
one test that only typed a few chars
corresponding events table
@sharpboy2008 I would suggest rolling back to Cypress 3.7.0 in the meantime for your issue.
jennifer-shehane
on 8 Jan 2020
@jennifer-shehane What about my issue? Did you try recreate this scenario in 3.8.1?
pawelrudnicki
on 8 Jan 2020
I ran into this issue as well today. The strange thing is that I started using cypress a few days ago with 3.8.1, and it worked fine until today, when it suddenly started failing 100% of the time. it varies a bit how far it gets, for instance sometimes it gets to "person@ema", other times it gets to "[email protected]" etc...
I've now fixed it by reverting all the way back to 3.4.0, where the failure rate seems to be 0%.
We do use angularjs though, so the problem may be in there. Still strange that it worked for a few days perfectly.
VesterDe
on 14 Jan 2020
Dear great community, i have had the same error, the problem is that Cypress is typing to fast in it. The default input typing speed is 10ms.
I solved my problems since i added an option while typing in an input field.
You have just to increase the delay of typing!
Like ->
cy.get('.loginInput').type('TestUser', {delay:70} );
delays between 70 and 100 was the perfect range i tried it with 50 ms, but it failed onced.
since i updated it to 70 ms, the test now have been run over 600 times! without error.
Sorry for my bad english, i'm not a native english speaker.
Best wishes from germany
Ali-AlHalass
on 15 Jan 2020
I too am seeing this issue after upgrading from v3.4.1 -> v3.8.2. Using it as such:
cy.get(this.numberField).type(searchCriteria).type('{enter}');
The searchCriteria we pass in could be 123456 and typically it will type {enter} after 12345, but missing the 6.
We are testing an Angular 8 project with Cypress.
coleman17
on 21 Jan 2020
FWIW, this solves the issue for me in v.3.8.2:
cy.get('.loginInput').click(); // Add this line
cy.get('.loginInput').type('TestUser');
bnss
on 27 Jan 2020
I had a similar issue with this where
cy.contains('label', 'exampleLabel').find('input').focus().type('some text here');
only resulted in typing out the first character s.
I was able to get around this issue by adding { force: true } option to type().
My current cypress version is 3.8.2.
Minho-Lee
on 29 Jan 2020
@Codex0607 This solved my issue perfectly, although the timing was a bit off. It seems to me that this issue happens when there is an eventListener attached to the input on key events. In my case, I was doing something quite intensive on each keypress so it seemed to miss some keystrokes. It could be, and I haven't tested this, that if a login form is validating input on key events it could potentially cause it to miss.
yaakov123
on 3 Feb 2020
@Codex0607 This solved my issue perfectly, although the timing was a bit off. It seems to me that this issue happens when there is an eventListener attached to the input on key events. In my case, I was doing something quite intensive on each keypress so it seemed to miss some keystrokes. It could be, and I haven't tested this, that if a login form is validating input on key events it could potentially cause it to miss.
our company has a validation on input fields too, you can try to add after your type() an assertion like: type('test1'). should('have.value','test1').
or select your input field and do a callback on it within a then block and do the typing and the assertions in the then block.
Ali-AlHalass
on 3 Feb 2020
I have similar issues in 3.8.0 and it also happens around ~30-50% of the time like some of the posts above reported.
When printing the keyboard events table shows that each character was triggered, but for me the input stays completely empty (not partially filled like some other reports here)
Another common theme for me is that all my forms that fail with this are inside a dialog which is positioned over a position:fixed container backdrop (similar to the popular Bootstrap Modal component, etc.)
If I have 5 inputs that are typed into one after the other, usually only the very first input remains unfilled, and the 2nd+ is filled properly.
The only solution/hack that works for me for now is doing cy.wait(1000) (lower delays also didn't seem to help) before I'm about to type into something.
yk1711
on 7 Feb 2020
We just encountered this in 4.0.2 . Our's was a very simple
cy.get('[data-schema-key="amount"]')
.clear()
.type("5000");
It would only type 5 in 4.0.0 and in 4.0.2 sometimes gets 50 or 500. We have many other uses of type around our tests but only this one was failing.
I repeated the same command after it and second time it types the full 5000.
We added the {force: true} and it's fine now.
It happens running just this test in isolation, not sure how I could try reproduce it but if there's anything we can do to try help find the cause let me know.
lynchem
on 19 Feb 2020
I was suspecting that maybe our implementation of the input was causing the issues (we are using a modified version of the html input in React) but I just verified that the cy.get('input').type('Something') sometimes just doesn't trigger the onKeyDown event.
Edit: I thought I had tried adding {force: true} but seems like I didn't because adding it now solved most of the issues. Is this a hint to what is going wrong? I tried to read about what it does but not sure how the inputs can be in an "actionability state" only sometimes.
saschahofmann
on 24 Feb 2020
same issue here on 3.8.3
just updated from 3.4.1 - here is ok :)
raulyarooms
on 25 Feb 2020
Please provide a way to reproduce
Hey everyone, we know this issue is happening and we really, really do want to fix this regression. But as of yet no one has provided a completely reproducible example that we can currently run that fails in 3.4.1 and passes in 3.5.0.
Please provide a reproducible example - the entire HTML & test code that we can fully run on our system.
We do not currently have an example to reproduce this bug, so this is no work has been done on this issue and cannot be fixed until that is provided.
jennifer-shehane
on 26 Feb 2020
I just tried setting up an example using cypress 3.8.3 and react. So far all tests pass consistently. I will have another look later. If someone else wants to have a try, here is the repo feel free to commit.
saschahofmann
on 26 Feb 2020
This is happening to me only on a textarea no matter what option I set (delay, force, etc)
hoscarcito
on 2 Mar 2020
@hoscarcito Please can you provide HTML + test code to reproduce?
jennifer-shehane
on 2 Mar 2020
After one day trying this, I've just found the error. Our app is written in React and eveytime we change the location it fires a setTimout to fire a redux action to clean alerts after x seconds. This leads to weirds re-renders in the middle of the tests that, even if they don't update the component at all, it prevents Cypress to keep typing. Also, we had other issues with elements being apparently unmounted. But again, this was all related to firing this redux action with the timer to clear notifications.
Thanks!
hoscarcito
on 3 Mar 2020
I can confirm that we are witnessing this behaviour too.
willgdjones
on 19 Mar 2020
We migrated to cypress 4 and typing seems to work more reliably.
I still haven't managed to build a minimal example but discovered a case where cypress actually revealed a bug in the current setup. I have two instances of the same react component which update an external state onBlur. I ran:
cy.findByDisplayValue('[store_id]').type('{selectall}COUNT([store_id])')
cy.findByDisplayValue('[revenue]').type('{selectall}SUM([revenue])', forceOption)
The first line outputs this to the console:
and the second one:
The first one behaves as expected while the second input is not updated at all, since it's apparently typing on the wrong element.
I figured that typing on the first second element actually triggered the onBlur on the first and changed it to manually trigger the onBlur (if anyone has a better idea than cy.findByDisplayValue('COUNT([store_id])').focus().blur() I'd be excited to hear it). And voila the second input types just as fine.
I tested this behaviour manually and indeed if you type in the first input you need two clicks to be able to type in the second. Why exactly that happens, I am not sure but thought I'd share.
saschahofmann
on 25 Mar 2020
my problem is similar but different, on first page load (it's a php site) cypress does not type the first few letters correctly, but does type in the final letters! adding a wait() helps. but ugh.
dwenaus
on 26 Mar 2020
We do not currently have an example to reproduce this bug, so this is no work has been done on this issue and cannot be fixed until that is provided.
What if this is caused by a race condition? It may not be possible to provide a reliable means of reproducing the bug.
cshouts-tasc
on 27 Mar 2020
The only way I've found to avoid this issue is to use 3.4.x.
willgdjones
on 27 Mar 2020
Not sure if this will constitute an example. But we have a page which has a bunch of text inside a p tag. If you want to edit the content then click on a button opens a tiny mce modal. The modal has a text area that sits inside an iframe. I use js chance to generate a random paragraph which I then use cy.type() to fill in and then click ok to close the modal and then validate the p tag in the page for the updated text. I consistently got it to fail where only 3/4ths of the text got typed in even with adding the delay option
shivasrini
on 31 Mar 2020
we faced the same issue with 4.1.0. several options has been tried like delay/force.
It failed about 5-10 % of the time.
chengzh2008
on 9 Apr 2020
Please provide a way to reproduce
Hey everyone, we know this issue is happening and we really, really do want to fix this. But as of yet no one has provided a completely reproducible example that we can currently run that fails in 3.4.1 and passes in 3.5.0.
Please provide a reproducible example - the entire HTML & test code that we can fully run on our system.
We do not currently have an example to reproduce this bug, so no work has been done on this issue and cannot be fixed until that is provided.
jennifer-shehane
on 22 Apr 2020
We are using React with hooks, and we had the similar problem. It happened also in chrome.
const LoginForm = () => {
const [email, setEmail] = useState('');
const formRef = useRef(null);
const [analyticsSent, setAnalyticsSent] = useState(false);
useEffect(() => {
const onFocus = () => {
if (!analyticsSent) {
sendAnalytics();
setAnalyticsSent(true);
}
if (formRef.current) formRef.current.addEventListener('focus', onFocus);
return () => {
formRef.current.removeEventListener('input', onFocus);
};
}, [analyticsSent, formRef]););
return (
<form onSubmit={handleLogIn} ref={formRef}>
<input value={email} onChange={(e) => setEmail(e.target.value) } />
...
</form> )
...
}
So the problem is that the <form>'s input eventlistener callback somehow interferes with <input />'s onChange. By sending analytics and setting local state, onChange callback isn't called.
I worked this around by instead of using input event on the <form>, I use focus event on the <input/>:
formRef.current.querySelector('input').addEventListener('focus', onFormFocus);
I'm actually having a custom hook for form analytics, thats why i add custom event listeners on the formRef instead of form's input.
phuwin95
on 24 Apr 2020
I am seeing this behaviour also (React hooks in use as in above, if that matters).
BUT! I think I've pinpointed the problem to be easily reproduced by simply (and quite oddly) clicking the Cypress UI, e.g. collapsing and expanding the test spec hierarchy on the auto-scrolling left pane. Fails both with Electron and Chrome (on MacOS). But once you leave the browser window untouched (or running tests in headless mode), the whole test suite passes...
So the clicks on Cypress part of the UI during testing steals the focus on the test browser. Maybe it's intended and unavoidable, but certainly wasn't obvious to me.
Cypress v4.5.0.
kimmosaarinen
on 6 May 2020
Hola comunidad, a mi me está ocurriendo el mismo problema que no terminar escribir una cadena de texto en la versión 4.5. Me está ocurriendo en este mismo momento. Al parecer no hay una solución, pero al menos aquí dejaré el caso. Un saludo.
andrewjruss7
on 8 May 2020
Hi @jennifer-shehane, I may have found a way to reproduce it.
Actually, the first time I launch my test, everything is always ok.
But as soon as I relaunch the test (either by ctrl+S in my editor, or directly from the icon in the Test Runner), it systematically fails : only a part of my string is typed.
For example, if my code is :
cy.get('#keyword').type('something quite long to type') then :
- the first time I launch my test, everything is ok : the input contains 'something quite long to type'
- but if I relaunch my test (for example, if there is an error further in my test, so I have to make a modification on my test code), the typing is partially truncated (and from one time to the other, never at the same place) : sometimes I get 'somethin', sometimes ''something qui', etc.
Adding a delay worsens the typing bug, since the string is cut as soon as the first character is typed.
Ex : cy.get('#keyword').type('something quite long to type', {delay: 300}) => only 's' is typed.
To the contrary, each time I relaunch my test from scratch (i.e. I close the Test Runner window and relaunch my test from my tests list), the typing is ok.
I hope this will help!
Let me know if you reproduce it too this way.
Rose-Lutz
on 13 May 2020
Using the GUI from yarn cy:open I ran through my spec 10 times. I got 4 passes with 6 failures on an email input cy.get('input[name="email"]').type('[email protected]'); which was typing an incomplete email and failing the validation. [pass, pass, fail, fail, fail, fail, fail, fail, pass, pass]
In the attachment you can see the command next to the resulting form input.
Using the cypress-file-upload plugin and running testing in Chrome 81.
"cypress": "^4.5.0",
"cypress-file-upload": "^4.0.6",
I believe its a fairly vanilla install currently, this is the first test. I'll try and create a project from scratch to attempt to replicate.
I'm interacting with an iframe directly before the email input
cy.get('iframe[width=304]')
.then($iframe => {
const $body = $iframe.contents().find('body');
cy.wrap($body)
.find('.recaptcha-checkbox-border')
.should('be.visible')
.click();
});
cy.get('input[name="email"]').type('[email protected]');
cy.get('input[name="firstName"]').type(name);
cy.get('input[name="lastName"]').type('testLname');
cy.get('input[name="phone"]').type('12344321');
The odd thing I find is cypress has proven to be reliable between async callbacks. Its such an odd thing for it to fail on.
ofhope
on 22 May 2020
I am experiencing this on 4.6.0. Can't provide example but in my case this won't happen at the very first time cypress types, for instance, my test first authenticates typing successfully but after navigating through the application and typing again it truncates the strings. What is solving the issue for me every time is to use clear method just as
cy.get('input[name="input.lastName"]').clear().type(lastName).should('have.value', lastName);
rodrigosanchezg8
on 25 May 2020
Hi Team, I am able to reproduce the above mentioned issue with 4.7.0.
Here is the code snippet:
/// <reference types="Cypress" />
describe("visit the link", function () {
it("visiting website", function () {
cy.visit("www.amazon.com");
cy.get("#twotabsearchtextbox").type("Mobile phone");
cy.get(".nav-search-submit .nav-input").click();
});
});
AnuragGalvanize
on 28 May 2020
4.8.0 - bug is still there.
voyy
on 18 Jun 2020
I am experiencing this on 4.6.0. Can't provide example but in my case this won't happen at the very first time cypress types, for instance, my test first authenticates typing successfully but after navigating through the application and typing again it truncates the strings. What is solving the issue for me every time is to use
clearmethod just as
cy.get('input[name="input.lastName"]').clear().type(lastName).should('have.value', lastName);
Still flaky for me, but what did help was the delay parameter when putting input, something like:
cy.get(EMAIL_LOCATOR)
.type(emailConst, { delay: 100 })
.should('have.value', emailConst);
voyy
on 24 Jun 2020
any update?
abhinaba-ghosh
on 25 Jun 2020
@rodrigosanchezg8 thanks, the .clear() solved it for me as well 100% in 4.9.0 where i was still encountering it.
But ended up using something like this based on @voyy 's feedback:
Cypress.Commands.overwrite("type", (originalFn, element, text, options) => {
if(!options || !options.delay){
options = {delay: 100}
}
return originalFn(element, text, options)
});
FilepCsaba
on 26 Jun 2020
Also not sure if this is in any way a relevant or even valid info, but in our team we only have this issue on windows machines, on MacOs this never happens.
FilepCsaba
on 29 Jun 2020
I've definitely experienced this on MacOSX
Sent via Superhuman ( https://sprh.mn/[email protected] )
On Mon, Jun 29, 2020 at 14:49:59, FilepCsaba < [email protected] > wrote:
Also not sure if this is in any way a relevant or even valid info, but in
our team we only have this issue on windows machines, on MacOs this never
happens.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (
https://github.com/cypress-io/cypress/issues/5480#issuecomment-651097697 )
, or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AAND4KDIUQPXPX774VZQ6NDRZCEXPANCNFSM4JFJRB7Q
).
willgdjones
on 29 Jun 2020
Updated to 4.9.0 and same problem
Akta3d
on 1 Jul 2020
Also not sure if this is in any way a relevant or even valid info, but in our team we only have this issue on windows machines, on MacOs this never happens.
It is same for every OS. I have same issue with headless electron on ubuntu in docker.
Reloyaro
on 1 Jul 2020
I'm able to reproduce this given the example below.
it('test', () => {
cy.visit('www.amazon.com')
cy.get('#twotabsearchtextbox')
.type('Mobile phone')
.should('have.value', 'Mobile phone')
})
This is happening because a 'toaster' pops up midway through typing (sometimes) on the site which takes focus away from the input during type. You can see where the type events are going for each keyboard event by clicking on the TYPE in the command log and opening the events table in your DevTools.
If your application calls focus away from the currently focused input during typing, this can cause this behavior.
jennifer-shehane
on 2 Jul 2020
I've had this problem on our own app. Interestingly, I was able to solve it by using the same solution I had to Issue #7306. This leads me to guess that this problem is related to how Cypress deals with re-rendered text inputs. Though I could be wrong.
Here is a link to my comment in that issue: https://github.com/cypress-io/cypress/issues/7306#issuecomment-642917537
Adil-Iqbal
on 2 Jul 2020
@jennifer-shehane The bug happens for me without the input losing focus when using react ionic's "ion-textarea" in [email protected]. The text that ends up in the input is "Hy, how are you?" (missing the "e").
Adding a delay of 500ms before typing solves it, but I can't go this route in good conscience.
EDIT
I should mention adding a 500ms delay only solves it _most_ of the time. It will still happen, making my tests undeterministic.
austin43
on 3 Jul 2020
I could reproduce this issue in one of the text boxes
I have typed the input, assert for it and it fails.
Fyi, While typing, we fetch data from API.
vrknetha
on 13 Jul 2020
I too have experienced this problem.
I have the cy.get('something').type() in around 15 different input fields on a test I do, and most of the times I run, around 13 or 14 are typed perfectly, but most of the time there is one or two that misses letters. And its completely random, both which field this happens and also how many letters it misses.
If I run, for example:
cy.get('#AnyId1').type("TypingAnythingHere")
cy.get('#AnyId2').type("TypingAnythingHere")
cy.get('#AnyId3').type("TypingAnythingHere")
Sometimes it will run perfect, but sometimes one of the items will be typed incomplete, such as "TypingAnythi", or "Typ", and its completely random which one will this happen, or how many letters it will miss.
gcostafinkel
on 6 Aug 2020
I am experiencing this on 4.6.0. Can't provide example but in my case this won't happen at the very first time cypress types, for instance, my test first authenticates typing successfully but after navigating through the application and typing again it truncates the strings. What is solving the issue for me every time is to use
clearmethod just ascy.get('input[name="input.lastName"]').clear().type(lastName).should('have.value', lastName);
This helped me as well!
peterkemenyas
on 12 Aug 2020
My version is 4.12.1, this bug still there.
But using clear() before type() can improve.
derting
on 17 Aug 2020
Updated
I had this issue on 5.0.0 when filling out a form input in a modal on a CMS Website (no react, angular etc). It would only fill a few characters and it was super inconsistent how many it would fill before it moved on and failed the assertion.
As a workaround, I first click the field, type into it (which doesn't always work), so I then clear and then type again, I also add a 100ms delay. This workaround while not ideal has had consistent results with 100+ successful runs.
cy.get('input[name="input.lastName"]')
.click()
.type(lastName, { delay: 100 });
cy.get('input[name="input.lastName"]')
.clear()
.type(lastName, { delay: 100 })
.should("have.value", lastName);
I hope this helps.
all9lives
on 19 Aug 2020
Whenever I try to type this text similar to this: 'test multi choice tile-8561b7ee-2290-4588-97c3-7729ea854be9' --> 2 out 5 times it fails as it either does not type completely or some characters are missing.
srilakshmishankar
on 27 Aug 2020
Hello @srilakshmishankar
I tried a suggestion from previous comments and used clear() method and after the type() method worked just fine
peterkemenyas
on 27 Aug 2020
Hello @srilakshmishankar
I tried a suggestion from previous comments and used clear() method and after the type() method worked just fine
I tried with clear() too but it does not help. May be I need to add delay but it is too slow with delay.
srilakshmishankar
on 27 Aug 2020
Hello @srilakshmishankar
I tried a suggestion from previous comments and used clear() method and after the type() method worked just fineI tried with clear() too but it does not help. May be I need to add delay but it is too slow with delay.
Did you chain the clear() and type()?
peterkemenyas
on 27 Aug 2020
Hello @srilakshmishankar
I tried a suggestion from previous comments and used clear() method and after the type() method worked just fineI tried with clear() too but it does not help. May be I need to add delay but it is too slow with delay.
Did you chain the clear() and type()?
Yes
srilakshmishankar
on 27 Aug 2020
I tried most of the solutions here and no use. Typing keeps failing and making our tests flaky. I spent a lot of time on this issue but not even able to manage with a workaround which works always.
srilakshmishankar
on 28 Aug 2020
Is there a reproducible example, a complete code repo we can run to see the problem?
Sent from my iPhone
On Aug 27, 2020, at 18:36, sri notifications@github.com wrote:
I tried most of the solutions here and no use. Typing keeps failing and making our tests flaky. I spent a lot of time on this issue but not even able to manage with a workaround which works always.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
bahmutov
on 28 Aug 2020
@bahmutov I haven't been able to build an isolated repro, but in Metabase we've seen it particularly with our SQL editor ( https://github.com/metabase/metabase/pull/12687/files ) where there's some auto-complete functionality as well as in one of our smoketests (see #7911).
I'll see if I can build a small repo with just those bits of code.
dacort
on 31 Aug 2020
Yeah that would be ideal
Sent from my iPhone
On Aug 31, 2020, at 13:09, Damon P. Cortesi notifications@github.com wrote:
@bahmutov I haven't been able to build an isolated repro, but in Metabase we've seen it particularly with our SQL editor ( https://github.com/metabase/metabase/pull/12687/files ) where there's some auto-complete functionality as well as in one of our smoketests (see #7911).I'll see if I can build a small repo with just those bits of code.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
bahmutov
on 31 Aug 2020
We also just ran into this issue, and none of the workarounds above seemed to help. However, we did find a fairly gross workaround which involves chaining together multiple .click().type('x') commands to type one character at a time.
Unfortunately, I also can't share any details about the application which is running into this issue as it's an internal application.
rabidsloth
on 2 Sep 2020
I am facing the same issue Cypress doesnot even finish typing a 11 character string 'AUtoChocBOM' it stops after typing A. ANy visibility on the progress of this fix would be appreciated
AnkitaRao
on 9 Sep 2020
Also having terrible issues w/ Cypress sometimes typing the entire string into some fields, but sometimes not typing the entire string, totally wreaking havoc. It is a Vue app.
stuarth-inova
on 9 Sep 2020
Please provide a small reproduction we can run to see it
Sent from my iPhone
On Sep 9, 2020, at 14:59, Stuart Holme notifications@github.com wrote:
Also having terrible issues w/ Cypress sometimes typing the entire string into some fields, but sometimes not typing the entire string, totally wreaking havoc. It is a Vue app.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
bahmutov
on 9 Sep 2020
From the above stories, and from my own experience trying, it is clearly quite difficult to create such a reproducible example.
I do understand how this benefits you when you are trying to debug an issue.
Nonetheless, is there now not sufficient evidence to suggest that there is an underlying issue that is giving many people problems which therefore warrants further investigation from Cypress?
Sent via Superhuman iOS ( https://sprh.mn/[email protected] )
On Wed, Sep 9 2020 at 8:24 pm, Gleb Bahmutov < [email protected] > wrote:
Please provide a small reproduction we can run to see it
Sent from my iPhone
On Sep 9, 2020, at 14:59, Stuart Holme notifications@github.com wrote:
>
Also having terrible issues w/ Cypress sometimes typing the entire
string into some fields, but sometimes not typing the entire string,
totally wreaking havoc. It is a Vue app.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (
https://github.com/cypress-io/cypress/issues/5480#issuecomment-689767214 )
, or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AAND4KABHXGUO2BMC4O5MSLSE7I5JANCNFSM4JFJRB7Q
).
willgdjones
on 9 Sep 2020
Unfortunately, there is not enough information for us to investigate it.
Mostly we suspect these issues to be caused by race conditions, something
we have been describing in our blog posts, all starting with "When Can ..."
that you can read at https://www.cypress.io/blog/
[image: Screen Shot 2020-09-09 at 4.48.32 PM.png]
On Wed, Sep 9, 2020 at 4:39 PM William Jones notifications@github.com
wrote:
From the above stories, and from my own experience trying, it is clearly
quite difficult to create such a reproducible example.I do understand how this benefits you when you are trying to debug an
issue.Nonetheless, is there now not sufficient evidence to suggest that there is
an underlying issue that is giving many people problems which therefore
warrants further investigation from Cypress?Sent via Superhuman iOS ( https://sprh.mn/[email protected] )
On Wed, Sep 9 2020 at 8:24 pm, Gleb Bahmutov < [email protected] >
wrote:>
>
>
>
>Please provide a small reproduction we can run to see it
Sent from my iPhone
On Sep 9, 2020, at 14:59, Stuart Holme notifications@github.com
wrote:>
Also having terrible issues w/ Cypress sometimes typing the entire
string into some fields, but sometimes not typing the entire string,
totally wreaking havoc. It is a Vue app.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (
https://github.com/cypress-io/cypress/issues/5480#issuecomment-689767214
)
, or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAND4KABHXGUO2BMC4O5MSLSE7I5JANCNFSM4JFJRB7Q
).—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cypress-io/cypress/issues/5480#issuecomment-689808991,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQ4BJUJFDANHQM35ETCLJ3SE7RX5ANCNFSM4JFJRB7Q
.
--
Dr. Gleb Bahmutov, PhD
Schedule video chat / phone call / meeting with me via
https://calendly.com/bahmutov
gleb.[email protected] @bahmutov https://twitter.com/@bahmutov
https://glebbahmutov.com/ https://glebbahmutov.com/blog
https://github.com/bahmutov
bahmutov
on 9 Sep 2020
Certainly seems like some sort of race condition. I've been trying for a few days, but can't reliably reproduce this.
We just experienced it the other day in a test and you can see in the image below the text should be select {{snippet: foo}}, but it ends up being select {{snippet: f}}oo. But then we rerun the test and it's fine. In every scenario we've experienced this, a rerun of the test usually works.
I _think_ you should be able to see the circleci runs since it was on a public branch if that's at all helpful
dacort
on 9 Sep 2020
Yes, after further examination our problem seems like a race condition.
Vue is rendering the elements really fast, but in one case our DB call can
be slow. BUT we started waiting on those routes - made it better, but still
an issue.
Now as far as we can tell sometimes Cypress grabs the element and starts
typing after the API call ends, but before Vue can render the data in the
field. And if the field is empty, apparently Vue deletes what Cypress has
typed so far.
In another case we have a button that appears to render before the js is
bound to it- so the desired action does not occur when Cypress clicks it
too quickly.
Is there any way for Cypress to peer into the inner workings of something
like Vue and wait until all of this js has loaded/finished executing?
Stuart
On Wednesday, September 9, 2020, Damon P. Cortesi notifications@github.com
wrote:
Certainly seems like some sort of race condition. I've been trying for a
few days, but can't reliably reproduce this.We just experienced it the other day in a test and you can see in the
image below the text should be select {{snippet: foo}}, but it ends up
being select {{snippet: f}}oo. But then we rerun the test and it's fine.
In every scenario we've experienced this, a rerun of the test usually
works.[image: image]
https://user-images.githubusercontent.com/1512/92657634-04603f00-f2aa-11ea-8645-23e711ec0925.pngI think you should be able to see the circleci runs
https://app.circleci.com/pipelines/github/metabase/metabase?branch=pull%2F13213
since it was on a public branch if that's at all helpful—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cypress-io/cypress/issues/5480#issuecomment-689839959,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARORV4E3AAI47AIHC2SED3SE7Z4ZANCNFSM4JFJRB7Q
.
stuarth-inova
on 10 Sep 2020
@bahmutov Think I've finally got a solid repro for this!
Check out https://github.com/dacort/cypress_type_repro
It'll require you to run the Metabase Docker image, but the test takes care of setting it up and shows both a failing and successful type test case. There is a drop list that pops up that could be causing the issue?
Let me know how else I can help! /cc @nemanjaglumac as he helped put together the repro.
dacort
on 15 Sep 2020
@dacort thank you - I can see the text disappearing, investigating in https://github.com/bahmutov/cypress_type_repro
bahmutov
on 17 Sep 2020
Ok, @dacort so I suspect this is event listener logic that has a delay in the popup
// always works
cy.get(".Icon-add_data").click();
popover().within(() => {
cy.wait(500)
cy.get("[contenteditable='true']").type("1+1+1+1+1+1")
cy.get('input.my1').click()
})
// sometimes works
cy.get(".Icon-add_data").click();
popover().within(() => {
cy.wait(400)
cy.get("[contenteditable='true']").type("1+1+1+1+1+1")
cy.get('input.my1').click()
})
How is that popup implemented? Is it a widget we can look in isolation to see its code?
bahmutov
on 17 Sep 2020
Yea @bahmutov very likely that's the case somewhere. I'm not yet sure if we can pull the widget out in an isolated fashion, but will probably poke more next week.
For context, the input field is TokenizedInput.jsx inside ExpressionEditorTextfield.jsx inside ExpressionWidget.jsx. So if something is going on, it's likely in one of those places. There is the "autocomplete" dropdown that shows up (see below) so my guess it's something to do with that. When we've run into this in other areas, it's been where some sort of autocomplete has popped up.
dacort
on 19 Sep 2020
don't know it useful or not, but this code works fine on my local dev environment (MacBook) but fails on QA environment (ec2 instance, linux) for some reason. Same version of Cypress on both environments.
Uncommenting cy.wait(200) fixes it on QA.
// Cypress: 5.3.0
// Browser: Electron 83 (headless)
it('test', ()=>{
// open Bootstrap modal popup
cy.visit(profileAccessPage)
.contains('button', 'Invite User').click()
// cy.wait(200)
// fill in email
cy.get('#recipient-email').clear().type(newUserEmail).should("have.value", newUserEmail)
})
```
1 failing
Timed out retrying
+ expected - actual
-'tech+cy-1'
+'[email protected]'
scmrus
on 6 Oct 2020
Using cypress 4.1.0 and had to instrument this workaround:
const type = (input, value) => {
[...value].forEach((c) => {
input().click();
input().type(c, { delay: 0 });
});
};
input must be a function that returns a cypress getter, i.e.
const input() => cy.get('input[name="email"])
We have a react app that uses controlled inputs. We respond to the onInput event and that is why the component is rerendered on each character that is typed. This work around types VERY slowly, so use it sparingly.
egucciar
on 12 Oct 2020
In case this helps anyone, I found type() consistently failed if an XHR request came in during the type operation. I looked like some components re-rendered and maybe type lost focus(?). I solved it by cy.waiting on the request before calling type().
saschwarz
on 28 Oct 2020
Upgrading to 5.5.0 fixes the issue for me 👍 Thanks team!
willgdjones
on 2 Nov 2020
Upgrading to 5.5.0 fixes the issue for me too 👍 Thanks team!
scmrus
on 5 Nov 2020
There have been multiple issues mentioned here, some of which are unrelated to the change introduced in 3.5.0 which was the original bug report. There is a PR open to fix this issue's original bug.
https://github.com/cypress-io/cypress/issues/5480#issuecomment-694222091 has existed before 3.5.0 and therefore wont be fixed alongside this issue. Possibly a new issue, "cy.type starts before framework listeners are ready", could be opened instead
Bkucera
on 20 Nov 2020
The code for this is done in cypress-io/cypress#9254, but has yet to be released.
We'll update this issue and reference the changelog when it's released.
![cypress-bot[bot] picture](https://avatars3.githubusercontent.com/u/8908513?v=4&s=40)
cypress-bot[bot]
on 20 Nov 2020
Released in 6.0.0.
This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v6.0.0, please open a new issue.
cypress-bot[bot]
on 24 Nov 2020
Related issues
SecondFlight
·
3Comments
weskor
·
3Comments
rbung
·
3Comments
scottcrowe
·
3Comments
jennifer-shehane
·
3Comments
Most helpful comment
@jennifer-shehane , I am unsure what you're looking for. Simply use cy.type() on an input field with a string with mixed case and it will reproduce the problem. This happens on various login screens around our app which I cannot share as they are proprietary. Please let me know what you're expecting for this bug to be investigated