Note: unlike most of my posts, this one actually is written by AI. Claude Sonnet helped me identify the key technical issues. As always, please verify for yourselves.
Subject: Bug report: Substack editor memory leak (website interface)
(~1.5GB retained, growing unbounded during editing)
Dear Substack Team:
I’m reporting a reproducible memory leak in the Substack post/note editor that causes severe browser slowdown during writing sessions.
Symptom: After writing/editing in the Substack editor for more than one minute, Firefox becomes progressively slower until it’s nearly unusable. The slowdown scales with time spent in the editor tab.
Environment:
- Firefox 152, Windows 11
- Reproduced on the note/article editor at substack.com
Diagnosis steps taken:
- Captured a Firefox Profiler performance recording during a slow session. The Substack content process showed 50% of all samples spent in `nsCycleCollector_collectSlice` (Incremental Cycle Collection), with the process’s memory graph climbing continuously and never releasing.
- Took an about:memory snapshot while the tab was bloated. The Substack tab’s content process (Isolated Web Content) was using approximately 1.54GB of resident memory – more than the browser’s entire Main Process and GPU process combined.
- Exported the full memory report (about:memory > Save…) and analyzed the breakdown for that process. The two largest contributors were:
– ~140MB and ~121MB in plain JS Object instances, in two separate window/realm contexts
– ~60MB and ~52MB in JS Array instances, same two realms
– An additional ~40MB in internal object storage (”slots”).
Notably, detached DOM nodes were NOT the issue (only ~8MB and ~6.5MB respectively) – this rules out a typical “leftover DOM elements” leak. The memory is concentrated in plain JS Objects and Arrays that appear to be accumulating without being cleared, duplicated across two separate realms (suggesting the same logic is running in both the top window and an embedded iframe, e.g. an editor iframe).
Suspected Cause: Some client-side state (possibly an undo/history stack, autosave/change-event log, or state-management store) appears to be storing full snapshots or appending entries without ever truncating or clearing old ones, causing unbounded growth over the course of an editing session.
I would be happy to provide the full profiler capture and/or raw about:memory JSON report if that would help your engineering team track this down. This is very reproducible on my end after just a minute of active writing or editing.
Thanks for looking into this,
Wyvern Dryke