Find a memory leak

A useful leak test repeats a lifecycle that should return to roughly the same state.

Suppose opening a dialog creates DOM nodes, listeners, and a large data model. Use this procedure:

1. Load the page and take a baseline heap snapshot.
2. Open and close the dialog several times.
3. Allow garbage collection to occur; a DevTools collection button can make snapshot comparison more repeatable, but application code cannot rely on it.
4. Take another snapshot and compare object groups.
5. Repeat the cycle to see whether the same groups keep accumulating.

A larger heap alone is not proof. The browser may retain capacity, the application may populate an intentional cache, and collection timing varies. Look for instances whose feature has been closed but that remain reachable after repeated cycles.

Detached DOM nodes are a clue, not the root cause. Select an unexpected object and follow its retaining path. The path can reveal an event listener on window, an active timer, a closure, or a cache entry that still references the object.

Fix ownership at the lifecycle boundary:

• remove listeners or register them with an abort signal
• disconnect observers
• cancel timers and animation frames
• unsubscribe from data sources
• limit and expire cache entries
• release references to detached trees

Run the same cycle after the fix. The strongest evidence is that the unwanted instance count no longer grows while the feature still behaves correctly.