ResizeObserver loop limit exceeded

I am getting a lot of “ResizeObserver loop limit exceeded” exceptions reported from my users (through Sentry). It seems to only come from Chrome 64+ on mobile (so no polyfill).

https://github.com/WICG/ResizeObserver/issues/38 gives a bit of context, and using requestAnimationFrame seems to fix the bug (see https://github.com/cerner/terra-core/pull/1647).

Would you be open to implement a fix for this?

[ashen-dawn]

I had to do some research on this for work, and found a bit of background information that may be helpful. If I get a bit of time I’ll try to make a reproducible code sample (although I can’t promise that right now).

Background Info:

I believe this error is the same as the one listed here as part of the ResizeObserver spec. Chromium based browsers seem to use a different error message than that exact one, but in Firefox the error message is the same.

This error is emitted if a resize event happens and the browser is unable to notify all the listeners within that frame. In our app this happens because we update some fairly global React state directly from the react-resize-detector callback, which triggered several React components to re-render at once. Because React re-renders synchronously, this delayed the browser’s paint until a frame or two later, causing this error.

I’m not sure if the browser eventually does notify all the listeners and this warning just means there was a dropped frame, or if some of them just get skipped for that event? If it’s the former then this is potentially an error that is safe to ignore, if it’s the latter than probably not.

Why this error is hard to replicate:

Because ResizeObserver emits its errors as events on the window object, these normally don’t get logged. The tricky thing is that because monitoring platforms like Sentry often use window.addEventListener() or something similar to capture errors, they do see these errors. This was a problem for our team as Sentry reported hundreds of these errors happening, but it took us a long time to eventually replicate them, because they don’t get logged.

You can manually log them by running window.addEventListener('error', function(e) { console.error(e); }); in the developer tools, and all further events will be printed to the console.

The solution that worked for us:

The root of this problem seems to be React re-rendering (or any computationally intensive work, really) happening as a direct result of the resize event. If you defer that work to after the resize event has been handled, the browser is totally fine with it because it’s not being prevented from delivering all of its event notifications in time. The simplest method of doing this for us was to replace:

dispatch({
  payload: {
    desktop,
    mobile,
    tablet,
  },
  type: "CHANGE_BREAKPOINTS",
});

with:

setTimeout(() => {
  dispatch({
    payload: {
      desktop,
      mobile,
      tablet,
    },
    type: "CHANGE_BREAKPOINTS",
  });
}, 0);

in our app. This defers the React update until the next pass of the event loop, gets it out of the event context, and avoids the issue. Obviously the code your app is running to trigger re-renders or other work will be different, but I believe that idea of running this work in a delayed callback should resolve the issue for any application.

I believe this also explains why requestAnimationFrame() also worked as a fix (albeit with side effects) - it also defers execution of the callback until after the current event.

I’m not sure if adding a setTimeout to the library would be an appropriate fix, as it may introduce similar bugs - but at least as a user of the library my team has found that this prevents the issue in our app and we felt it would be helpful to share.

[maslianok]

Sorry, guys, I have no quick fix for this problem.

Earlier we blindly added requestAnimationFrame without understanding the problem, which caused other bugs to appear.

---

For now we can try to workaround the problem by using refreshMode/refreshRate props:

{ refreshMode: 'debounce', refreshRate: 0 }

---

Any help would be greatly appreciated. Even if someone could provide a code snippet where the bug appears.