How can I fix an issue in Cypress where an element becomes detached from the DOM during test execution?

General Discussions
, ,
1

Cypress throws the following error:

This DOM element likely became detached somewhere between the previous and current command.

I’m trying to run the test block below, but it fails intermittently, likely due to re-renders.

I’ve read that using Cypress guards (like re-querying or adding waits) might help, but I’m not sure how to apply them properly.

js
Copy
Edit
it('Add-Income', () => {
  cy.get('.add_btn').click();
  cy.get(':nth-child(1) > .input_container > input').type('45000');
  cy.get(':nth-child(2) > select').select('4');
  cy.get(':nth-child(3) > select').select('32');
  cy.get(':nth-child(4) > .input_container > input')
    .invoke('removeAttr', 'type')
    .type('12-12-1990{enter}');
  cy.get('.title > span').click({ force: true });
});

it('Add-Expenditure', () => {
  cy.get('.add_btn').click();
  cy.get('.overlay_card > :nth-child(4)').click();
  cy.get(':nth-child(1) > .input_container > input').type('45000');
  cy.get(':nth-child(2) > select').select('4');
  cy.get(':nth-child(3) > select').select('32');
  cy.get(':nth-child(4) > .input_container > input')
    .invoke('removeAttr', 'type')
    .type('12-12-1990{enter}');
});

What’s the best way to apply Cypress guards in this scenario to avoid detached DOM errors?

Should I use should(‘be.visible’), wait(), or something else?

2

Yeah, I’ve run into this issue a bunch of times, especially with dynamic UIs where elements re-render fast.

The trick that worked for me is chaining a Cypress guard like .should('exist') or .should('be.visible') right after cy.get(), but before interacting.

For example:

cy.get('.add_btn').should('be.visible').click();
cy.get(':nth-child(1) > .input_container > input')
  .should('exist')
  .type('45000');

These guards ensure Cypress doesn’t proceed until the element is stable in the DOM. It’s not bulletproof, but it’s been the cleanest way to avoid flaky “detached” errors in my test suite.

3

This one took me a while to figure out, but re-querying elements closer to when you actually interact with them helps avoid issues with Cypress guards.

What I do is wrap the interaction logic in a function or just refetch the element again before typing or clicking.

Instead of:

cy.get('input').type('value');

I’d do:

cy.get('input').should('exist').then(($el) => {
  cy.wrap($el).type('value');
});

Or even re-get:

cy.get('input').should('exist');
cy.get('input').type('value');

This has worked well when my React components are fast to update but sometimes unmount/remount between interactions.

4

I know Cypress frowns on arbitrary waits, but sometimes a small cy.wait(200) after DOM-triggering actions like .click() helps smooth things out , especially in apps with transitions.

Also, I wrote a custom command that uses Cypress guards internally to always wait for a stable element:

Cypress.Commands.add('getStable', (selector) => {
  cy.get(selector).should('exist').should('not.have.attr', 'aria-busy', 'true');
});

Then I replace cy.get() with cy.getStable() and avoid those annoying detachment errors.

For highly dynamic UIs, combining Cypress guards with small delays in key places can really stabilize things.