Replay: rrweb `Mirror.removeNodeFromMap` never descends into shadow roots, so every removed web component leaks its shadow tree
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 85/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript, typescript
- Domain
- frontend, performance
Research direction
Start in packages/rrweb-snapshot/src/utils.ts at Mirror.removeNodeFromMap, alongside the existing isNativeShadowDom and isShadowRoot helpers. Run the minimal custom-element reproduction and verify that removing a shadow host also removes its serialized shadow-tree nodes from idNodeMap, so detached ShadowRoot objects are no longer retained.
Written by the indexing model from the issue text.
Description
Is there an existing issue for this?
- I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
- I have reviewed the documentation https://docs.sentry.io/
- I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases
(observed on 10.63.0; verified that 10.74.0 bundles the identical code via@sentry/rrweb-snapshot2.43.2, and that 2.44.0 and rrweb master still contain the same method)
How do you use Sentry?
Self-hosted/on-premise
Which SDK are you using?
@sentry/browser
SDK Version
10.63.0 (code unchanged in 10.74.0)
Framework Version
No framework. Server-rendered Symfony app, Stimulus controllers, UI built from Stencil web components (open shadow roots).
Link to Sentry event
n/a (memory growth, no event)
Reproduction Example/SDK Setup
Sentry.init({
dsn: __YOUR_DSN__,
integrations: [Sentry.browserTracingIntegration()],
tracesSampleRate: 1,
replaysSessionSampleRate: 0,
replaysOnErrorSampleRate: 1.0,
});
// added later on requestIdleCallback
Sentry.addIntegration(Sentry.replayIntegration({
maskAllText: true,
maskAllInputs: true,
blockAllMedia: true,
}));
Minimal reproduction without any framework:
<script>
customElements.define('x-box', class extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: 'open' }).innerHTML =
'<style>:host{display:block}</style><span><slot></slot></span>';
}
});
</script>
<div id="host"></div>
<script>
// start Replay first (buffer or session mode, both affected), then:
const host = document.getElementById('host');
let i = 0;
setInterval(() => {
host.innerHTML = '';
for (let k = 0; k < 100; k++) {
const el = document.createElement('x-box');
el.textContent = 'item ' + (i++);
host.appendChild(el);
}
}, 500);
</script>
Steps to Reproduce
- Start Replay on a page that renders open-shadow-root custom elements (Stencil, Lit, or the plain element above).
- Re-render a region repeatedly so that shadow hosts are removed and recreated (table paging, list refresh, the interval above).
- Take a heap snapshot after a few hundred re-renders and look at the retainers of the detached
ShadowRootobjects, or count entries of the rrwebMirror.idNodeMap(the object withidNodeMap: MapandnodeMetaMap: WeakMap).
Expected Result
When a shadow host is removed from the document, all nodes rrweb serialized for it, including the nodes inside its shadow root, are dropped from the mirror. Memory returns to baseline once the removed elements are garbage collected.
Actual Result
Mirror.removeNodeFromMap only recurses over n.childNodes and never looks at n.shadowRoot, so the nodes inside the shadow root of every removed host stay in idNodeMap forever (@sentry/replay/build/npm/esm/index.js, removeNodeFromMap, corresponds to packages/rrweb-snapshot/src/utils.ts in rrweb). Because idNodeMap holds strong references, this pins the detached ShadowRoot, its slots, text nodes, style elements and adopted stylesheets for the lifetime of the recording.
Measured on our production admin app (Chrome 140, Stencil components, one datatable being paged programmatically 50 times per run):
| before | after 50 page changes | |
|---|---|---|
| live DOM nodes (light + shadow) | ~6,000 | ~6,000 |
rrweb idNodeMap entries |
12,068 | 13,580 |
retained ShadowRoot objects |
1,640 | 3,360 |
Retained JS heap grows about 1 MB per interaction and never comes back; the leaked map entries are exclusively shadow-tree nodes (<slot>, Text, <span>, <style>, nested hosts). Retainer chain from the heap snapshot:
Window.open (patched closure) → context → Mirror (G) → idNodeMap (Map) → <slot> / <style> → ShadowRoot
Users who keep a tab open for a working day end up with tabs of 3 to 4 GB.
A second, smaller consequence: Replay flips from buffer to session mode after the first captured error, so in practice the recorder, and with it this leak, runs for the rest of the session even with replaysSessionSampleRate: 0.
Additional Context
- The gap is in rrweb-snapshot and exists in upstream
rrweb-io/rrwebmaster and ingetsentry/rrwebas well;isNativeShadowDom/isShadowRoothelpers are already available in the same file. A fix is to recurse into(n as Element).shadowRootinremoveNodeFromMapin addition tochildNodes. Happy to open the matching PR against the fork if you prefer to take it there rather than upstream. - Related but not covering this: #7474 (shadow DOM support investigation), #6615 (corrupt replay with web components), #14001 (DOM node counts in replay).
- Dominant language
- TypeScript
- Stars
- 8.7k
- Forks
- 1.9k
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 543
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from getsentry/sentry-javascript
-
Task
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
getsentry/sentry-javascript#24558 · 1 comment ·
-
Task
Difficulty 1/5 Under an hour Newbie friendliness 90/100
getsentry/sentry-javascript#24557 · 1 comment ·
-
Task
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
getsentry/sentry-javascript#24556 · 1 comment ·
-
Task
Difficulty 1/5 1-3 hours Newbie friendliness 90/100
getsentry/sentry-javascript#24555 · 1 comment ·
-
Task
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
getsentry/sentry-javascript#24547 · 1 comment ·
All issues in getsentry/sentry-javascript
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
agilepathway/label-checker#640 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
copse-dev/agent-pane#2953 ·
-
agentic-workflows
Difficulty 1/5 Under an hour Newbie friendliness 85/100
githubnext/rig#534 ·
-
automation missing-model model-sync provider:pioneer
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
anomalyco/models.dev#7701 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
clerk/javascript#9852 ·