.type() does not enter a - or + after a valid number in an input of type number #6150
Comments
|
I was actually never really able to get the assertion to pass in any version, but the behavior of typing is definitely different from 3.7.0.
<html>
<body>
<input type='number'>
</body>
</html>
it('type 123-', () => {
cy.visit('index.html')
cy.get('input').type('123-').should('have.value', '123-')
})
it('type 1+1', () => {
cy.visit('index.html')
cy.get('input').type('1+1').should('have.value', '1+1')
})3.4.13.7.03.8.2Manual typing |
jennifer-shehane
added
the
type: regression
cypress-bot
bot
added
the
stage: ready for work
|
Yeah, into my fix #6055 I've already thought of some corner cases like this one. Since I didn't found a satisfying solution, I've only resolved the actual issue and didn't pushed fix futher more. I would like to share here some of my though: First, some code lines to look at: Basically, Cypress do validation on the typed data regarding of the input type. Here is what happen with your examples:
We see two things:
Also, if you manually enter the value "123-" or "1+1" and then try to get the So, we are kind of stuck between the rock and a hard place here. And I don't see any "really" satisfying solution. Because:
I would really like to hear any suggestion about that topic. |
jennifer-shehane
added
v3.7.0 🐛
|
This is still an issue in 4.10.0. |
|
@jennifer-shehane, Has the community decided on this? I'd be happy to make the behavior match the OP. That is, allowing .type() to set the value on to things that are prohibited by standard. This of course would break what @bkucera wrote regarding the standards and will throw browser console errors. My vote would weigh in on allowing the behavior, if there isn't an overriding design value of the project. My reasoning is that since the behavior is available when manipulating the DOM (programmatically or manually) it may actually be a state that end users need to test. The fact that the state can exist and someone is asking to test it is pretty solid to me. |
|
Probably the real-events plugin does this correctly. I haven't tried though. https://github.com/dmtrKovalenko/cypress-real-events But in the end we need to implement something closer to that plugin instead of simulating the type. |
cypress-bot
bot
added
stage: routed to team brandon
and removed
stage: ready for work
cypress-bot
bot
added
stage: routed to e2e-auth
and removed
stage: routed to team brandon
labels
|
Sorry to bring that up again. |
|
This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided. |
|
This issue has been closed due to inactivity. |
Current behavior:
Similar to to now closed 6055, if I try to type
123-into an input of type number, the field only contains 123. This is a bit of an edge case, we use these valid characters to make an invalid number to test field validation messages for our NumberTextField component.This behavior is a discrepancy between Cypress and manual in Chrome as strings like 123- and 1+1 can be entered manually. Our tests are passing in 3.7 but failing in 3.8.2
Desired behavior:
.type()allows valid characters to be added to an input of type number even if the positioning of the characters makes the end value invalid.Steps to reproduce:
use
.type('123-')on an input of type number.use
.type('1+1')on an input of type number.Versions
Chrome 79, Windows 10, Cypress 8.3.2
The text was updated successfully, but these errors were encountered: