waitForElement can leave its MutationObserver running for all future tests

[RoystonS]

• DOM Testing Library version: 5.5.0
• node version: 10.16.0
• npm (or yarn) version: yarn 1.16.0

Relevant code or config:

  async function waitForListToBeReady(id: number) {
      console.log('getCancelButton', id);
      await waitForElement(() => {
        console.log('running waitForElement predicate', id);
        return getRowCount() === 44;
      });
      console.log('waitForElement', id, 'completed');
    }

    bdd.it('runs some stuff in test1', async () => {
      doSomeSetup();
      await waitForListToBeReady(1);
      expect(something).to.be.true;
    });
    bdd.it('runs some stuff in test2', async () => {
      doSomeSetup();
      await waitForListToBeReady(2);
      expect(something).to.be.true;
    });
    bdd.it('runs some stuff in test3', async () => {
      doSomeSetup();
      await waitForListToBeReady(3);
      expect(something).to.be.true;
    });
  });

What you did:

Used waitForElement in one test, with the Intern testing framework.

What happened:

Every test that calls waitForElement causes another DOM MutationObserver to be created, and not cleaned up, and every DOM change causes all prior waitForElement predicates to be re-evaluated. The tests get slower and slower.

The output:

getCancelButton 1
running waitForElement predicate 1
waitForElement 1 completed
running waitForElement predicate 1
getCancelButton 2
running waitForElement predicate 2
running waitForElement predicate 1
waitForElement 2 completed
running waitForElement predicate 1
running waitForElement predicate 2
getCancelButton 3
running waitForElement predicate 3
running waitForElement predicate 1
running waitForElement predicate 2
waitForElement 3 completed
running waitForElement predicate 1
running waitForElement predicate 2
running waitForElement predicate 3
running waitForElement predicate 1
running waitForElement predicate 2
running waitForElement predicate 3
[repeat a couple of hundred times as the test framework writes its output to the DOM]

This shows that, despite the fact that waitForElement has completed, it's still listening for DOM changes and still re-evaluating its predicate.

Reproduction:

See above. A full repro would require setting up an Intern deployment, which I can do, but it'll take a little longer.

Problem description:

The tests get slower and slower as the number of DOM MutationObservers accumulates, especially as the existing test predicates start to cause exception throws.

Suggested solution:

I'm not sure. Looking at the code, it looks like waitForElement uses setImmediate to queue up the .disconnect call of the MutationObserver, but it looks like, as my tests run, nothing ever yields sufficiently to allow this callback to run, so the .disconnect call gets pushed back until all the tests complete. (I'm running on Chrome, which doesn't have native setImmediate, so DTL is using a polyfill which uses postMessage to simulate the effect.)

Removing the setImmediate call would cause the MutationObserver to be shut down synchronously, and that would fix this issue, but I don't know why the setImmediate call is there: presumably somebody added it for a good reason?

[kentcdodds]

Hi @RoystonS,

Well, I wasn't sure why it was needed either, but I think there's probably something we can do to solve #99 (which is why it was added) and your issue as well.

I'm not certain of the best way to go about this. Maybe if we use setTimeout instead?

If you could prototype something that works for your situation and then make a PR for that, we'll give it a look.

[kentcdodds]

I think this is solved in beta. Would you mind giving it a try?

npm install @testing-library/dom@beta
# npm install @testing-library/react@beta

Thanks!

[kentcdodds]

🎉 This issue has been resolved in version 7.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀