cypress-io / cypress

Fast, easy and reliable testing for anything that runs in a browser.
https://cypress.io
MIT License
47.05k stars 3.19k forks source link

Flaky failed on action type() due to disabled element #28172

Open kduy969 opened 1 year ago

kduy969 commented 1 year ago

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: image

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

jennifer-shehane commented 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.

yang commented 1 year ago

@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.

kduy969 commented 1 year ago

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"

kduy969 commented 1 year ago

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.

provokateurin commented 10 months ago

Same problem here, but for me it fails almost all the time (more like 90%)

Regenhardt commented 9 months ago

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.

alexeyhimself commented 8 months ago

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!

TestIsTest001 commented 5 months ago

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

DaveEvans-Thalamos commented 4 months ago

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