-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support to cy.type() for inputs of type date, time, month, week #27
Comments
I also have an issue with For example: |
Please fix this... |
Will also note that the docs at https://docs.cypress.io/v1.0/docs/type#section-known-issues seem to be inconsistent with the behaviour I'm seeing. The docs suggest that to enter a date I may simply write If the docs are in fact out of sync with the behaviour of Cypress currently, it might be a good idea to update the docs to reflect that. If the docs are suggesting this might be the expected fix, then it might also be good to note that as well. Of course, it would also be good to just get the issue fixed as well. Seems to me that as I can enter dates/numbers/special fields by hand just by tabbing and typing, the same should be easily accomplished with Cypress. I might try mucking about with tabbing a bit to see if it works with these special cases at all. |
Will also point out that it has been 13 months since @jennifer-shehane brought this issue to light. Has there been any movement on this? |
There has actually. In fact this will be fixed in the next release (0.20.0) |
Very cool! Thanks for the update @brian-mann. I presume it will be fixed in accordance with what the docs already specify? Namely, it'll require entering the preformatted final value? |
Correct. It will require entering the final value that will actually get set per the spec. We'll validate it up front and fire the keystrokes, but the value won't appear until its all done. |
Very cool. Thanks for the update!
…On May 22, 2017 5:18 PM, "Brian Mann" ***@***.***> wrote:
Correct. It will require entering the final value that will actually get
set per the spec. We'll validate it up front and fire the keystrokes, but
the value won't *appear* until its all done.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#27 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAkeu3NpqZF79cRCu2nJrLEybSvCh9S5ks5r8fuLgaJpZM4EElhL>
.
|
The code for this is done, but this has yet to be released. We'll update the issue and reference the changelog when it's released. |
Fixed in |
Test summaryRun details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
I still have an issue with this. If I let the user type in a date in the preformatted final value, I still get this error when I use should(): expected '<tr#opening_date_level_1..opening_date_container>' to have value '01-12-2022', but the value was ''. |
@sharandaa try to use that
|
When I use command
cy.type()
for inputs of type date, time, month, and week the value is not updated for the input. The type command needs to do special logic to inject the values (or do special click / selects / types) due to the formatting / dropdown nature of these inputs.Date Example
This example's assertion will fail and say
expected input to have value of '1985-11-15', but got ''
Time Example
This example's assertion will fail and say
expected input to have value of '00:15:00', but got ''
Month Example
This example's assertion will fail and say
expected '<input#month.form-control>' to have value 'February 2012', but the value was ''
Week Example
This example's assertion will fail and say
expected '<input#week.form-control>' to have value '20, 2016', but the value was ''
The text was updated successfully, but these errors were encountered: