react: TypeError: Cannot read property 'body' of null

This method:

https://github.com/facebook/react/blob/b87aabdfe1b7461e7331abb3601d9e6bb27544bc/packages/react-dom/src/client/getActiveElement.js

Is throwing this error in jest:

I realize that this method is checking only when the document is undefined. However, using jest looks that is setting sometimes the document to null, causing this error.

To reproduce it, I’m testing a callback that is using an async task:

 const asyncTask = useCallback(async (data) => {
    dispatch({ type: 'FETCH' })

    try {
      const res = await MyService.asyncMethod(data)
      dispatch({ type: 'SUCCESS', data: res })
    } catch (e) {
      dispatch({ type: 'ERROR' }) // This dispatch throw this error in jest
    }
  }, [])

About the test, I’m just mocking the service and testing the different scenarios.

I imagine that is related that the dispatch from the useReducer, that it’s used inside the catch, is fired when the component maybe is unmount? @gaearon In this case how can I do a safer dispatch inside a callback method?

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 8
Comments: 20 (5 by maintainers)

Commits related to this issue

Fix TypeError in getActiveElement During tests (with react-testing-library) a test randomly fail with "TypeError: Cannot read property 'body' of null" in the getActiveElement. It appears that sometim... — committed to ishristov/react by ishristov 5 years ago

Most upvoted comments

Closing this, happy to reopen if someone shares a reproducing case.

+32

threepointone on Sep 3, 2019

I have the same issue with react testing library, the only difference is that the test pass locally while fails on CI.

+31

AvraamMavridis on Apr 30, 2020

@threepointone I’ve come up with a reproducible example, although to be fair it would still need investigation to pin down exact/specific cause:

https://github.com/ivarprudnikov/test-react-enzyme-body-null

ivarprudnikov on Nov 28, 2019

I also encountered this issue today. It looks like global.document is being set to null when Jest’s JSDOM environment is being torn down: https://github.com/facebook/jest/blob/72c920e4f8feff5f2b319c4111da8c989de54995/packages/jest-environment-jsdom/src/index.ts#L109

Since getActiveElement never checks for null, we’re seeing this error.

This might just be a problem with my test though, because it seems that getActiveElement is being invoked after Jest thinks the test finished.

rzane on Jul 31, 2019

The PR doesn’t solve the bug, it hides it.

threepointone on Nov 9, 2019

Can anybody provide a reproducing case please? 😃 That’s the fastest way to get an issue fixed.

gaearon on Jul 31, 2019

i ran into this problem with react router v5 and react v18 using react testing library v13 i was persisting my component throughout different states using

import '@testing-library/react/dont-cleanup-after-each'

turns out i needed to run cleanup() after all my tests and it works now! e.g.

import { cleanup } from '@testing-library/react'

...
describe('whatever', () => {
    afterAll(() => { cleanup() })
})

i feel like the issue had something to do with test cleanup, as mentioned earlier in this thread

ggblee on Apr 12, 2023

Hey folks, here is another reproduction of this issue with React and Jest (using React Testing Library this time): https://repl.it/repls/PeskyStimulatingBetaversion

It makes sense that whenever this happens the fix should be within the test itself, ultimately. However, the current error message is not very obvious.

There is already an example of such message here: https://github.com/facebook/react/blob/3e94bce765d355d74f6a60feb4addb6d196e3482/packages/shared/invokeGuardedCallbackImpl.js#L78. The getActiveElement check could also do something like that.

And of course in both of these situations checking for null in addition to undefined would also be helping to correctly show this descriptive message.

So, again, it is true that the root cause is ultimately outside of React code, but this could be a better developer experience when diagnosing it. Hope this helps and thanks for your tireless efforts!

unframework on Apr 10, 2020

I’m hitting this as well. It’s hard to reproduce since it doesn’t occur on every run. Only noticed after implementing a bunch of tests and merging my changes, which caused others builds to break (randomly). Makes jest feel pretty flaky.

This definitely seems to be related to async thunks. Definitely still a big current issue, so don’t understand why it’s closed.

Note: I checked one of my failing async thunk actions and it didn’t have any console.log so not seeing that correlation on my end. This is a private repo so unfortunately can’t share.

cchamberlain on Nov 9, 2019

It would be very useful to get some information about which user-space function failed when this failure mode occurs. Is that possible? If not, maybe something like this could be added to react-dom.development.js:

 if (doc === null) {
          console.error("getActiveElement: document is null. This implies that an async process has finished after React has been mounted.")
          return null;
}

This will notify the user about the error - i.e. not hide it - but it will not crash the whole app.

tarjei on May 28, 2021

The most likely cause is that there’s some asynchronous work pending after your test completes, and it tried to update the dom after jest finishes running its tests and cleansup the jsdom instance. There’s not much that React can do here, since it has to be fixed in the test itself, by either cancelling that work, or waiting till it finishes before exiting the test.

That said, it’s hard to comment without a reproducing example. Keeping this issue open wouldn’t serve a purpose. If you can share a git repo with a reduced usecase that reproduces the error, even if only intermittently, I would be happy to help debug or give some pointers.

threepointone on Nov 9, 2019