feat(install): clear bloated profile caches on upgrade, add tron clean - #74
Merged
Conversation
… clean` Chromium's disk caches have no ceiling that matters here. Service-worker CacheStorage is quota-managed per origin, so a handful of heavy sites can carry a profile into the gigabytes on their own. Past roughly a gigabyte the cost stops being disk and starts being latency: the CacheStorage index is consulted on navigation, and once bloated, scrolling and tab switching go with it. The failure is gradual and then sudden, so it reads as "the browser broke today" — a profile that had reached 3.9G, with 1.4G of CacheStorage, is what prompted this. Clearing three directories took it to 534M and the sluggishness went away. `tron upgrade` now clears Cache, Code Cache and Service Worker once they exceed TRONBROWSER_CACHE_LIMIT_MB (default 1024, 0 disables). None of those hold bookmarks, passwords, history or cookies, so it costs a re-download and nothing else — you stay logged in everywhere, which is what makes this better than chrome://settings/clearBrowserData, where clearing service workers means clearing cookies too. The threshold matters: the auto-upgrade check runs daily, and clearing a healthy profile every day would cost everyone a re-download for nothing. `tron clean` does it on demand, implemented in the CLI rather than by re-running the installer — cleaning a bloated profile is exactly when you don't want to need the network. Neither path will unlink anything while the browser is running; the profile is memory-mapped, and pulling it out from under Chromium yields a corrupt profile rather than a clean one. Tests cover the cleanup against a fake profile: caches go, bookmarks, cookies, history, login data and IndexedDB stay, the threshold and the kill switch are honored, and TRONBROWSER_DATA is respected. The `tron` CLI's copy is generated inside a heredoc, so `sh -n` never sees it — it was extracted and checked with sh, dash, and a live run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ThreatCrush Security Scan93 finding(s) HIGH/CRITICAL: 6 | MEDIUM: 87
…and 43 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
ralyodio
marked this pull request as ready for review
August 3, 2026 16:29
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #72, from the same debugging session.
What actually caused the slowdown
Not DNS, not TronBrowser's code, not the engine. The profile had grown to 3.9G, with 1.4G in
Service Worker/CacheStoragealone. Clearing three directories took it to 534M and the sluggishness went away.Service-worker CacheStorage is quota-managed per origin, so a few heavy sites can carry a profile into the gigabytes with nothing to stop them. Past roughly a gigabyte the cost stops being disk and becomes latency — the CacheStorage index is consulted on navigation, and scrolling and tab switching go with it. It degrades gradually and then suddenly, which is why it reads as "the browser broke today" when nothing changed at all.
What this adds
tron upgradeclearsCache,Code CacheandService Workeronce they exceedTRONBROWSER_CACHE_LIMIT_MB(default 1024;0disables). None of those hold bookmarks, passwords, history or cookies — it costs a re-download and nothing else, and you stay logged in everywhere. That's what makes it better thanchrome://settings/clearBrowserData, where the only option that clears service workers also clears cookies and signs you out of everything.The threshold is load-bearing: the auto-upgrade check runs daily, and clearing a healthy profile every day would cost every user a re-download for nothing.
tron cleandoes it on demand. Implemented inside the CLI rather than by re-running the installer — cleaning a bloated profile is exactly when you don't want to need the network.install.sh clean --if-largeruns the same threshold-gated passtron upgradeuses.Neither path unlinks anything while the browser is running. The profile is memory-mapped; pulling it out from under Chromium gives you a corrupt profile rather than a clean one, so a running browser gets a warning instead.
Tests
apps/web/test/install-clean.test.tsruns the realinstall.shagainst a fake profile:Bookmarks,Cookies,History,Login DataandIndexedDBsurvive--if-largeleaves a small profile alone, and clears past the limitTRONBROWSER_CACHE_LIMIT_MB=0disables the automatic pass but not an explicittron cleanTRONBROWSER_DATAis respected, and the default location isn't touched when it's overridden8 tests pass.
sh -nanddash -nclean.The
tronCLI's copy of this lives inside a<<'TRON'heredoc, sosh -n install.shnever parses it — a real gap in how this file has always been checked. I extracted the generated CLI and verified it separately withsh -n,dash -n, and a live run against a fake profile (freed 5MB, kept Bookmarks/Cookies/IndexedDB).Not covered
do_upgrade's call into the cleanup isn't exercised by an automated test —do_upgraderesolves the latest release over the network. The function it calls is tested throughclean --if-large; the one-line call site is by inspection.🤖 Generated with Claude Code