Skip to content

Browser error“ResizeObserver loop completed with undelivered notifications”

The console, a red development overlay, a Cypress test or Sentry reports ResizeObserver loop completed with undelivered notifications (older Chrome versions said ResizeObserver loop limit exceeded). A resize observer callback changed the size of an element during the same frame, so the browser held some notifications back to the next frame and fired an error event on window. Often the page looks fine and the source is a chart, editor or UI library.

Short answer

If it comes from your own ResizeObserver callback, stop the callback from changing the size it watches in the same frame: only update when the size really changed, or move the update into requestAnimationFrame. If it comes from a library and the layout is correct, update the library and filter the message out of the dev overlay, tests and error tracking; it is an error event on window, not an exception in your code.

Why the loop happens, and the fix

  1. 01

    A callback that resizes what it observes

    “If you don't intend to have an infinite loop, you should make sure your resizing code does not trigger the resize observer callback.” MDN, ResizeObserver: Observation errors

    Setting a width, height or content in the callback changes the size again, which needs another notification in the same frame. Skip the update when nothing changed, or defer it to the next frame.

    let lastWidth = 0;
    const ro = new ResizeObserver(([entry]) => {
      const width = Math.round(entry.contentRect.width);
      if (width === lastWidth) return;
      lastWidth = width;
      requestAnimationFrame(() => setColumns(width));
    });
  2. 02

    A real loop that keeps growing

    “Note that this only prevents user-agent lockup, not the infinite loop itself.” MDN, ResizeObserver: Observation errors

    If an element grows every frame and the message repeats nonstop, the browser is only protecting itself. Find the callback that feeds its own size back into the layout.

  3. 03

    A library’s observer, with a layout that looks right

    Charts, rich text editors, virtual lists and UI kits use ResizeObserver internally. Update the library first. If the page looks and works right, the message is harmless noise.

  4. 04

    A dev overlay or error tracker treating it as a crash

    webpack-dev-server shows window errors in its overlay, and error trackers report them. Filter this one message out rather than hiding all errors.

    // webpack.config.js
    devServer: {
      client: {
        overlay: {
          runtimeErrors: (error) => !/ResizeObserver loop/.test(error.message),
        },
      },
    },
    
    // Sentry
    Sentry.init({ ignoreErrors: [/ResizeObserver loop/] });

Checked against the vendor’s docs on : MDN: ResizeObserver.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Related: React “Maximum update depth exceeded” · React “Too many re-renders” · “Uncaught (in promise)”

Questions

More on this error

Is it safe to ignore?

Usually, when it comes from a library and the layout is right: the browser delivers the held-back notifications in the next frame. Do not ignore it when an element keeps growing or flickering; that is a real loop in a callback.

Why does it only show in development or tests?

Users never see console errors, but dev overlays, Cypress and error trackers listen for every error event on window, and this message is one. That is why the same page can look fine in production.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; Simon replies by email, usually within one business day.