mirror of
https://github.com/hoornet/vega.git
synced 2026-05-30 16:29:26 -07:00
bc4c72d6a0
Commit 214c42b (v0.12.6) added auto-detection of content-addressed
Blossom URLs (64-hex SHA-256 paths) as <img> elements. Blossom is
widespread in modern Nostr feeds — every feed page started rendering
3-5x more <img> elements. Combined with WebKitGTK's weak decoded-
bitmap eviction, feed scrolling grew the WebKit web process to
8-12 GB and triggered WebKit's self-kill threshold with:
Unable to shrink memory footprint of process (9022 MB) below
the kill threshold (8192 MB). Killed
Disable BLOSSOM_URL_REGEX in parseContent(). Real Blossom images
shared via standard upload flows (with proper extensions) still
render. Proper reintroduction (HEAD request + Content-Type
validation, or known-server whitelist) planned for v0.12.9.
Also restore feed depth caps to pre-crisis values now that memory
is under control:
- MAX_FEED_SIZE 30 → 200 (v0.12.6 baseline)
- fetchFollowFeed limit 30 → 100
- fetchGlobalFeed fetch 80 → 100
- Following tab slice 30 → 100
The earlier 30-caps were themselves OOM firefighting that shipped
in v0.12.7 and were no longer needed.
Memory verified 2026-04-16: oscillates 1.1-1.6 GB across all tabs
(Global / Following / Trending / Media / profile / thread) under
heavy use with embedded relay enabled. No crashes. Elastic cache
behaviour rather than monotonic leak — memory spikes briefly on
content loads and reclaims within seconds.
See private_docs/WEBKIT_OOM_INVESTIGATION.md for the full
investigation (4 days of chasing symptoms before finding the
one-line regex as the real cause).