Open kduy969 opened 1 year ago
@kduy969 Is the element disabled at any time? It could be a timing issue - where this attribute exists, fails the test, but then immediately removed the attribute and that element without the attribute is used in the error message? If it has a disabled attr, you could add a check before to ensure it doesn't before attempting to type to give it more stability.
@jennifer-shehane Our code looks like this:
cy.get('inputselector:not([disabled])')
.should("not.be.disabled")
.clear()
.type(text);
And it fails maybe 30% of the time. We can trigger it by running this in a loop.
This happened immediately after we upgraded from cypress 13.2.0 to the newly released 13.4.0.
you could add a check before to ensure it doesn't before attempting to type to give it more stability
I can but I thought that kind of check was already made by Cypress when I used the "type" command. Refer to this doc: https://docs.cypress.io/guides/core-concepts/interacting-with-elements , at section "Checks and Actions Performed"
where this attribute exists, fails the test, but then immediately removed the attribute and that element without the attribute is used in the error message
Thanks, I will take a look but I think the log message should be accurate since dev rely on that to detect bug.
Same problem here, but for me it fails almost all the time (more like 90%)
Refer to #5830 and #5827, both were closed after someone posted the workaround .type('something', { force: true })
, which does work for using the element, but also invalidates the test as it will still type something if the element is actually disabled.
Guys, I just faced this issue on Cypress 13.7.0.
Investigated the problem and found, that the input fields are actually disabled on page load for a few milliseconds and then they get enabled by the app -- that's why it becomes unclear why does this "failed because it targeted disabled element" error appears for enabled element. And that's why it feels "fluky" for ones and stable for another. But looks like it's not a "fluky" bug in Cypress. It's in an app itself!
Try:
cy.wait(1000)
before
cy.get('input').type('hello');
and you'll probably will not see the problem anymore because the app will enable disabled elements during wait period.
Please, let me know if it worked for you and let's close this bug if it's really the app's behavior. Thanks!
I am checking that the input is not disabled before: cy.get('input').should('not.be.disabled') - pass cy.get('input').type() - fail
And the test is failing at the type part saying the element is disabled
I hit this due to a SSR hydration race condition. I found this strategy to wait for client hydration via a useEffect worked well for me. https://github.com/robipop22/dnb-stack/issues/3#issuecomment-1463031001
Current behavior
My command:
cy.get(...).find(...).type('something')
Most of the time the type action will be successful but sometimes I get this error due to disabled element:
There is a note said: "Ensure the element does not have an attribute named
disabled
before typing into it." but the input element showed in the screenshot ( reported by Cypress ) did not contains any attribute name 'disabled'.Desired behavior
The target element does not contain the "disabled" attribute, type action should not fail.
Test code to reproduce
cy.get(...).find(...).type('something')
Cypress Version
13.3.2
Node version
16.15.0
Operating System
macOS 14.0 (23A344)
Debug Logs
No response
Other
No response