morethanwords/tweb/master • 2b00c4d • 6 files, +289/-14 Release chat-list rows the virtual list drop

morethanwords/tweb/master • 2b00c4d • 6 files, +289/-14
Release chat-list rows the virtual list drops

A tab left open for two days held 597 custom-emoji renderers for a chat list
showing 38, and 1167 animation items against 2763 DOM nodes - 4.7 GB of process
memory, 1.5 GB of it GPU.

The chat list is the only owner of its DialogElements: deferredSortedVirtualList
stores them and nothing else holds a reference. But it dropped them silently -
removeItem, the tail trimmed by checkShrink on every scroll, clear, dispose, and
the value replaced when an id is re-added. A dropped DialogElement owns a
middlewareHelper, and the emoji status, its lottie/video players and the
subtitle's custom emoji are released only by that helper's destroy, so every
trimmed row leaked its renderer and the compositor worker kept its
OffscreenCanvas for the lifetime of the tab.

Give the list an onItemDiscard hook, fired on every path that drops a value for
good, and destroy the DialogElement behind it. onItemUnmount is deliberately not
that signal: it fires when a row merely leaves the rendered window and is kept
for re-mounting on scroll back. Only 'dialog' items are destroyed - the custom
ones are the caller's own objects, handed in as the key, and may be re-added.

CustomEmojiRendererElement also resurrected itself. Custom element reactions are
read off the prototype once, at customElements.define, so `this.connectedCallback
= undefined` never stopped the browser from calling it again: a destroyed
renderer that got re-inserted re-registered in emojiRenderers with its destroy()
already nulled out, and nothing could ever reclaim it. Replace the nulling
sentinel with an explicit `destroyed` flag, keep destroyed renderers out of
connectedCallback, and make destroy() idempotent - which also cuts the recursion
where clean() re-enters through the owner's onDestroy.

No time-based reclaim: a renderer can be legitimately detached and kept for
re-insertion, and there is no way from inside it to tell that apart from an owner
dropped without cleaning.

Adds window.memoryReport() - the JS heap accounts for none of the ImageBitmap and
OffscreenCanvas memory that dominates here, so the app has to count its own
registries. The detached figures are the ones to watch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

#webk