React 15 update: Uncaught TypeError: Cannot read property 'addEventListener' of null

[omerts]

Hello,

After updating to React 15.0.1, we are getting the following error:

Uncaught TypeError: Cannot read property 'addEventListener' of null

[jimfb]

Curious: What browser+version are you using when you see this error? Any chance it's Chrome 49? Can you reproduce on Firefox or any other browser?

[jimfb]

Also, can you provide a simple jsfiddle that demonstrates the issue?

[omerts]

@jimfb
Browser: chrome
Version: 46.0.2490.80

It also reproduces on firefox developer version 47.0a2 (2016-04-18)

It is a big application we have. I will try to create a small fiddle for reproducing.

[rickychien]

+1, I also saw this annoying message output every time after adopting React v15.

I found that typeError can be removed by deleting onClick event in div and is able to reproduce every time.

<div ... onClick={ onClick }></div>

to

<div ... ></div>

It happened on Chrome 49.0 and Firefox 48 (it threw TypeError: target is null) and Safar 9.1i.

[jimfb]

@rickychien @omerts If someone could try to produce a minimal repro / jsfiddle, that would be very helpful!

[jimfb]

@rickychien @omerts Another question, are you guys using ReactRouter and/or Redux?

[chelzwa]

We're seeing the same issue and are using both ReactRouter and Redux.

"react": "15.0.1",
"react-dom": "15.0.1",
"react-redux": "4.4.1",
"react-router": "2.3.0",
"redux": "3.3.1",

We see this even if we switch back to React 0.14.8, so I don't think it is specific to React 15.

We can only reproduce the issue by switching pages via react-router Links, not using browser back/forward buttons, so it's possible this is actually a react-router issue. Removing the onClick listener on the button fixes the issue for us as well.

Weirdly, our application has tons of other buttons with onClick listeners which get removed on route change which do not cause this error, so I'm having trouble figuring out how to repro.

[chelzwa]

Posted a Codepen over in #6371

[bencripps]

We are having this issue as well, both with 15 and 0.14.8 so I don't think its related to the newest release.

We started having this issue once we added a componentWillReceiveProps method to a stateful component. Once we removed this function, the error no longer occurs.

Our core dependencies are:

"react": "^15.0.1", 
"react-dom": "^15.0.1",
"react-redux": "^4.4.0",
"redux": "^3.3.1"

[gaearon]

I trimmed it down to a case that involves just React.

Fiddle: https://jsfiddle.net/ycLw3bbq/

var callbacks = [];
function emitChange() {
  callbacks.forEach(c => c());
}

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = { showChild: true };
  }
  componentDidMount() {
    this.setState({ showChild: false });
  }
  render() {
    return (
      <div>
        <ForceUpdatesOnChange />
        {this.state.showChild && <EmitsChangeOnUnmount />}
      </div>
    );
  }
}

class EmitsChangeOnUnmount extends React.Component {
  componentWillUnmount() {
    emitChange();
  }
  render() {
    return null;
  }
}

class ForceUpdatesOnChange extends React.Component {
  componentDidMount() {
    this.onChange = () => this.forceUpdate();
    this.onChange()
    callbacks.push(this.onChange);
  }
  componentWillUnmount() {
    callbacks = callbacks.filter(c => c !== this.onChange)
  }
  render() {
    return (
      <div key={Math.random()} onClick={function(){}} />
    )
  }
}

ReactDOM.render(<App />, document.getElementById('container'));

[gaearon]

Also, a few observations:

1. This only happens with onClick listeners which get queued here for Mobile Safari.
2. It seems related to batching. In the initial reproduction cases, I still used a <Link>, and I noticed that navigating inside setTimeout instead didn’t repro the problem, but wrapping it in unstable_batchedUpdates did. In my small repro above, I don’t use events or unstable_batchedUpdates, but it seems like doing this stuff inside the initial render batch has the same effect, so I’m calling forceUpdate and setState in componentDidMount.

[gaearon]

Replacing

  render() {
    return (
      <div key={Math.random()} onClick={function(){}} />
    )
  }

with

  render() {
    return (
      <img key={Math.random()} />
    )
  }

reproduces #6371 (Uncaught Invariant Violation: Must be mounted to trap events).

[gaearon]

I guess the issue here is that all transaction.getReactMountReady().enqueue calls in mountComponent seem to imply that unmountComponent is guaranteed to happen after getReactMountReady() callbacks have happened, but this may break if one of those callbacks can cause children component to unmount.

I think the sequence is:

1. Composite parent enqueues its componentDidMount in transaction.getReactMountReady()
2. DOM component mounts
3. DOM component enqueues DOM-related in transaction.getReactMountReady().enqueue
4. transaction.getReactMountReady() starts calling its callbacks
5. The composite’s componentDidMount was registered first, and it queues an update to the child which causes the DOM component to unmount
6. DOM component unmounts
7. transaction.getReactMountReady() proceeds and calls the unmounted DOM component’s callbacks