Is the 'DevTools console' leak valid?

[pr0g]

Hi there,

I've been playing around with memlab and it seems like an incredibly useful tool, but I'm still finding my way when it comes to understanding what are legitimate leaks, and what may be false positives or issues that can be ignored.

I have an incredibly simple little React demo which implements a list of elements that can be dragged and reordered. I'm using Vite, and I do a vite build and then vite preview before running memlab. My scenario.cjs file starts on a blank page (url()), moves to the page containing the list and presses and releases the first element of the list (action()), and then returns to the blank page (back()). When run, a leak is reported by memlab, it looks as follows:

MemLab found 1 leak(s)
Number of clusters loaded: 0

--Similar leaks in this run: 45--
--Retained size of leaked objects: 7.1KB--
[(GC roots)] (synthetic) @3 [308.1KB]
  --10 (element)--->  [(Global handles)] (synthetic) @23 [25.4KB]
  --75 / DevTools console (internal)--->  [Detached HTMLLIElement] (native) @67311 [7.1KB]
  --8 (element)--->  [Detached HTMLLIElement] (native) @68013 [400 bytes]
  --9 (element)--->  [Detached HTMLLIElement] (native) @68017 [400 bytes]
  --9 (element)--->  [Detached HTMLLIElement] (native) @68021 [400 bytes]
  --9 (element)--->  [Detached HTMLLIElement] (native) @68025 [400 bytes]
  --9 (element)--->  [Detached HTMLLIElement] (native) @68029 [400 bytes]
  --4 (element)--->  [Detached Text] (native) @2962 [80 bytes]

I may be misunderstanding, but it seems DevTools console is acting as a reference to these elements (I imagine to display them for debugging purposes) which is causing them to be reported as a leak. I just want to check if this is accurate, or if the above is more likely a genuine leak, and I'm doing something wrong in my React component.

Below is my scenario.cjs file, and I'm happy to share my rather hopeless React component too if that might be useful to see.

async function dragListItem(page) {
  const listItem = await page.waitForSelector("ul li:first-child");
  const box = await listItem.boundingBox();
  await page.mouse.move(box.x + box.width / 2, box.y + box.height / 2);
  await page.mouse.down();
  await page.mouse.up();
}

function url() {
  return "http://localhost:4173/blank";
}

async function action(page) {
  await page.click('a[href="/"]');
  await dragListItem(page);
}

async function back(page) {
  await page.click('a[href="/blank"]');
}

module.exports = { action, back, url };

Thanks very much for your help!

[JacksonGL]

Hi @pr0g, from what you've described, this does not look like a memory leak in your React component itself if some console.log(object) statements were added for debugging purpose. However, console.log object references is still a memory leak in either dev or prod environment. If the console.log statement is included in production code, it becomes a genuine issue because it can cause a memory leak in the end user's browser.

Why does console.log(obj) cause a leak? When an object is logged (e.g., console.log(obj)), the browser's DevTools console must retain a reference to that object so users can expand and inspect its content later in dev environment. Similarly, if the log statement is present in production, the object won't be garbage collected because the end user's browser needs to keep it available in case the end user later decides to open browser DevTools to inspect the log in the browser.

[JacksonGL]

By the way, it’s safer to log a string rather than an object reference. Strings don’t retain references to other objects, so they won’t unintentionally cause additional objects to be retained in memory, which could lead to larger leaks.

[pr0g]

Hi @JacksonGL, thank you very much for replying so quickly, your comment was very helpful.

I had a quick check and I don't have any console.log statements in the code (it's good to know that they can be the source of leaks though).

Just for completeness, here is my simple React component for reference (it's an incredibly simple test case to allow dragging and reordering of elements). It's likely not idiomatic React, and there may well be a better way to achieve the same effect, I just thought this would be an interesting widget to build to help learn a bit more about React (and as it happens Tailwind). This version is simplified and I've removed all the animation effects I was working on, but I still see the leak reported with the above scenario.

Example of what the component/widget looks like:

list.mp4

import { useState, useRef, useEffect, useCallback } from "react";

export function ReorderableList() {
  const [items, setItems] = useState<string[]>([
    "Item 1",
    "Item 2",
    "Item 3",
    "Item 4",
    "Item 5",
    "Item 6",
    "Item 7",
    "Item 8",
  ]);
  const [movingIndex, setMovingIndex] = useState(-1);
  const [availableIndex, setAvailableIndex] = useState(-1);
  const [mouseDelta, setMouseDelta] = useState([0, 0]);
  const mouseDownPosition = useRef([0, 0]);
  const ulRef = useRef<HTMLUListElement | null>(null);
  const liRef = useRef<HTMLLIElement | null>(null);
  const itemWidth = useRef(0);

  useEffect(() => {
    return () => {
      liRef.current = null;
    };
  }, []);

  const getStyle = useCallback(
    (
      index: number,
      movingIndex: number,
      availableIndex: number,
      itemWidth: number
    ) => {
      const style: React.CSSProperties = {};
      if (index === movingIndex) {
        style.transform = `scale(1.1)`;
        style.position = "relative";
        style.left = `${mouseDelta[0]}px`;
        style.top = `${mouseDelta[1]}px`;
      } else if (
        index >= availableIndex &&
        index < movingIndex &&
        movingIndex !== -1
      ) {
        style.transform = `translateX(${itemWidth}px)`;
      } else if (
        index <= availableIndex &&
        index > movingIndex &&
        movingIndex !== -1
      ) {
        style.transform = `translateX(${-itemWidth}px)`;
      }
      return style;
    },
    [mouseDelta]
  );

  const onPointerDown = useCallback(
    (index: number) => (e: React.PointerEvent<HTMLLIElement>) => {
      setAvailableIndex(index);
      setMovingIndex(index);
      liRef.current = e.currentTarget;
      // note: space-x-2 is 8px (see +8 below)
      itemWidth.current = liRef.current.clientWidth + 8;
      e.currentTarget.setPointerCapture(e.pointerId);
      mouseDownPosition.current = [e.clientX, e.clientY];
    },
    []
  );

  const onPointerUp = useCallback(
    (e: React.PointerEvent<HTMLLIElement>) => {
      liRef.current = null;
      if (movingIndex === -1) {
        setAvailableIndex(-1);
        e.currentTarget.releasePointerCapture(e.pointerId);
        setMouseDelta([0, 0]);
        return;
      }
      e.currentTarget.releasePointerCapture(e.pointerId);
      const newItems = [...items];
      const [extracted] = newItems.splice(movingIndex, 1);
      newItems.splice(availableIndex, 0, extracted);
      setItems(newItems);
      setMovingIndex(-1);
      setAvailableIndex(-1);
      setMouseDelta([0, 0]);
    },
    [availableIndex, items, movingIndex]
  );

  const onPointerMove = useCallback(
    (e: React.PointerEvent<HTMLLIElement>) => {
      if (availableIndex === -1) {
        return;
      }
      setMouseDelta([
        e.clientX - mouseDownPosition.current[0],
        e.clientY - mouseDownPosition.current[1],
      ]);
      const indexBefore = availableIndex - 1;
      if (indexBefore >= 0) {
        if (liRef.current) {
          const left =
            ulRef.current!.getBoundingClientRect().left +
            indexBefore * itemWidth.current;
          if (
            liRef.current.getBoundingClientRect().left <
            left + itemWidth.current / 2
          ) {
            setAvailableIndex(
              (currentAvailableIndex) => currentAvailableIndex - 1
            );
          }
        }
      }
      const indexAfter = availableIndex + 1;
      if (indexAfter < items.length) {
        if (liRef.current) {
          const left =
            ulRef.current!.getBoundingClientRect().left +
            indexAfter * itemWidth.current;
          if (
            liRef.current.getBoundingClientRect().right >=
            left + itemWidth.current / 2
          ) {
            setAvailableIndex(
              (currentAvailableIndex) => currentAvailableIndex + 1
            );
          }
        }
      }
    },
    [availableIndex, items.length]
  );

  return (
    <div className="flex flex-col">
      <ul ref={ulRef} className="flex flex-wrap gap-x-2">
        {items.map((item, index) => {
          return (
            <li
              key={item}
              onPointerDown={onPointerDown(index)}
              onPointerUp={onPointerUp}
              onPointerMove={onPointerMove}
              className={`select-none bg-slate-500 rounded-lg my-1 min-w-24 text-center ${
                index === movingIndex ? "text-red-500 z-50" : "text-black"
              }`}
              style={getStyle(
                index,
                movingIndex,
                availableIndex,
                itemWidth.current
              )}
            >
              {item}
            </li>
          );
        })}
      </ul>
      <p>Moving index: {movingIndex}</p>
      <p>Available index: {availableIndex}</p>
    </div>
  );
}

I'm pretty sure I'm doing something stupid, because when I look in the memory section of the Performance profiler in Chrome Dev Tools, I see many DOM nodes being created and destroyed (GCed) while dragging.

Maybe mixing style and className in the way I'm doing above is a bad idea, or perhaps I'm doing something wrong with how I'm handling the ul and li refs?

Please feel under no obligation to debug this code, but if there's anything that leaps out at you as wrong please let me know 😅

Thanks again for your help!

[JacksonGL]

@pr0g Thanks for sharing the React demo code. Indeed it doesn’t contain any console.log statements. I’m curious — have you observed any console output in the browser’s web console?

Here’s a simple way to check:

1. Run the memlab run --scenario ... command with the additional flags --headful --debug. This will launch a headful browser and pause at each step of your test scenario.
2. Manually click and open the browser’s web console in the MemLab-initiated browser window.
3. Press the Enter key to continue through each step of the scenario. Once the test ends, check if any objects are being printed in the web console. The console should show links to the source location where the objects were logged.

[pr0g]

Thanks for following-up @JacksonGL, I tried what you suggested, but the only thing I see in the console output is this...

Download the React DevTools for a better development experience: https://reactjs.org/link/react-devtools
Failed to load resource: the server responded with a status of 404 (Not Found)        favicon.ico:1

I'm not sure if this is related. Could the React DevTools message be causing it strangely, as the TEST version of Chrome that runs from memlab doesn't have the extension? Or could there be something else in the DevTools that's responsible?

Also just in case this is relevant, if I run vite dev (instead of building, and using preview), I see one more leak related to React:

--Similar leaks in this run: 1--
--Retained size of leaked objects: 276 bytes--
[Window] (native) @26923 [3.8KB]
  --3 (element)--->  [HTMLDocument] (native) @26921 [5.8KB]
  --9 (element)--->  [Range] (native) @1070 [80 bytes]
  --2 (element)--->  [HTMLDivElement] (native) @27125 [20.6KB]
  --__reactContainer$6mg109yvndw (property)--->  [FiberNode HostRoot] (object) @92257 [180 bytes]
  --__proto__ (property)--->  [Object] (object) @87245 [124 bytes]
  --constructor (property)--->  [FiberNode] (closure) @85929 [80 bytes]
  --context (internal)--->  [<function scope>] (object) @84879 [170.6KB]
  --return_targetInst (variable)--->  [Detached FiberNode a HostComponent] (object) @127613 [276 bytes]

However I think this might be an internal issue and related to StrictMode potentially, though I'm not 100% sure.

[JacksonGL]

@pr0g That's interesting. In that case, the DevTools console leak may come from either the browser itself or an extension. If your React app isn’t printing any objects, there’s no need for concern.

The reference chain involving return_targetInst appears to be an internal React issue and not related to your code.

[pr0g]

Hi @JacksonGL,

Okay that's great to hear, thank you for confirming.

My final question (and then I promise to leave you in peace 😅), is what would a legit memory leak in my component look like. Even if I just intentionally created one to see, that would be useful. Would a classic addEventListener without a corresponding remove suffice? Or if I stored a reference to a DOM node in a global for example?

It would just be handy to see what that looks like for comparison vs the Dev Tools leak.

Thanks very much for your help!

Tom

[JacksonGL]

Would a classic addEventListener without a corresponding remove suffice? Or if I stored a reference to a DOM node in a global for example?

@pr0g If addEventListener or the stored reference indirectly led to detached DOM elements or unmounted React fiber nodes being retained in memory, then yes, it could be detected and shown by MemLab.

The actual memory leak should be similar to the examples you shared, except the reference chain passes through closures or properties created by your JavaScript code. The reference chain gives you clue where your code may cause the memory leak. I have real-world examples from Meta's codebase, but I can't share them since they are not public. However, you can check out this doc for an example of what a memory leak on a demo app looks like.

[pr0g]

Sounds great, thank you again for your help @JacksonGL. I'll close this issue now 👍