What logdrop does​

logdrop is a small, self-hosted, PrivateBin-style drop-off, live now at logdrop.marvellouscode.works:

• No account needed to upload. Paste or drop your report, get a link back.
• Reading a capture requires maintainer auth. Even if the link ends up pasted somewhere public, it's useless to anyone but me.
• Uploads auto-expire on their own, no cleanup needed on either side. If you lose track of your own link, just capture and upload again, it's cheap to redo.

Privacy and security notes​

A few things worth being explicit about, since this exists specifically to handle data you'd rather not have sitting in public:

• The upload itself travels over HTTPS and lands on the same hosting as the rest of marvellouscode.works, not a third-party paste service.
• Only an authenticated maintainer session can read a capture. The upload link alone isn't a secret you have to protect, if it leaks, there's nothing to read behind it.
• Auto-expiry is enforced on the storage side, not by a cleanup job that could fail silently. Once a capture's TTL is up, it's gone, there's no "soft delete" or backup copy sitting around afterward.
• This isn't end-to-end encrypted like PrivateBin itself is. Since reads already require maintainer auth, we skipped client-side encryption for now to keep the tool simple, it's still a listed open question for later, not a settled no.
• A capture only ever contains what your browser already showed you in debug.html, TMS doesn't collect or transmit anything beyond that on its own, logdrop is just a safer place to put it than a public issue thread.

How to use it for a TMS bug report​

Instead of pasting a captureLogs/debug.html report straight into a GitHub issue or comment:

1. Open the Diagnostic page, enable captureLogs, reproduce the issue, then Copy report or Download report.
2. Upload it to logdrop.marvellouscode.works.
3. Paste the link it gives you into the issue instead of the raw report.

The bug report template, the FAQ, the Diagnostic page guide, the test-build troubleshooting page, and the report form on the site all point here now.

Tab Health scan reports (favicon/tab-group repair results) aren't affected, they're counts and status labels, not tab content, so pasting those directly into an issue is still fine.

This came out of #518. A few things are still open for later: uploading straight from TMS's own diagnostic UI instead of copy/paste, rate-limiting on the public upload endpoint, and whether client-side encryption is worth the added complexity given reads are already auth-gated.

It's not just for us​

The logdrop repo is public and open source, this isn't a TMS-only tool bolted onto our infrastructure. If you run your own project and want the same "reporters upload freely, only you can read it, it expires on its own" flow for your own bug reports or support requests, deploy your own instance, it's designed to be self-hosted by anyone. The one at logdrop.marvellouscode.works is simply the instance we run and keep available for TMS users specifically, it's not a shared public service for unrelated projects.

We're wide open to questions, suggestions, and contributions from outside on the project itself, issues and pull requests are welcome if you want to help make logdrop better.

Giovanni

What's new​

Separate auto-suspend timeout for battery power​

A new "Suspend tabs on battery power after" select, right alongside the existing plugged-in timeout in Settings. Set it once and tabs suspend more aggressively the moment you unplug, without touching your normal AC timeout at all. Defaults to "Same as when plugged in", so nothing changes unless you go set it.

"Never suspend app windows"​

On by default, like the pinned/audio/active-tab protections it sits next to. Keeps tabs open in an app-mode window, an installed PWA, or a site opened via "Create Shortcut → Open as window", out of automatic suspension. A manual "suspend this tab now" still works regardless, this only affects the automatic timer.

Suspend/unsuspend every tab in a tab group​

New page and tab-strip right-click menu items, plus two bindable keyboard shortcuts, acting on every tab sharing the clicked tab's group. Thanks to @mherkazandjian for building this, his first contribution to the project (#438) and part of a bigger tab-groups feature set still in progress for upcoming releases.

"Always reopen suspended tabs scrolled to the top"​

Opt-in. If you'd rather a suspended tab always reopen at the top of the page instead of wherever you left it scrolled, this does that, and overrides a #section link anchor in the URL too.

Reload also unsuspends background tabs​

Reloading a suspended tab you're not currently looking at, via a multi-tab selection, or right-click → Reload on an inactive tab, used to silently do nothing. Turn this on and it counts as an explicit unsuspend request, same as reloading the tab you're actively viewing already did.

A "What's new" screen after updates​

Exactly what you're reading the substance of right now, just inside the extension: a one-time modal on the Settings page after an update, showing only that version's changes, not the entire history.

What's fixed​

A rare but real out-of-memory crash​

Reproduced live, traced all the way to its actual mechanism, and fixed at the root rather than patched around the symptom: chrome.storage.onChanged was quietly broadcasting a full multi-megabyte copy of the diagnostic log buffer to every open suspended tab, every time anything was logged, and none of those copies ever got released. The whole log buffer moved to IndexedDB, which has no such broadcast, closing the gap entirely. Mostly invisible unless you use the debug page's captureLogs option, but the extension is more resilient across the board regardless. Full story: 9.0.3 in progress: chasing down a crash in TMS's own debug tooling.

Google Drive backup disconnecting on Brave and Vivaldi​

9.0.2 stopped the Drive connect flow from hanging on these browsers, but the token it fell back to was still short-lived and unreliable to renew, so accounts kept flipping back to "disconnected" after a backup or two. 9.0.3 replaces it with an authorization-code + PKCE exchange that mints a genuine long-lived refresh token, renewed by a direct call that doesn't depend on the browser at all, with the OAuth client secret moved server-side into a small proxy (tms-oauth-proxy) so it no longer ships inside the extension package. If you're on Brave or Vivaldi with Drive backup enabled, you'll need to reconnect once (Options → Backup → Connect) after updating, then it stays connected reliably. Full story: 9.0.3 in progress: a real fix for Drive backups disconnecting on Brave and Vivaldi.

Suspended-tab favicons stuck on the extension icon after a restart​

Mostly reported on Brave, Vivaldi, and Dia, where the automatic repair pass depended on a startup event those browsers don't fire reliably, so favicons reverted to TMS's own icon on every restart until manually fixed via Tab Health. A dedicated, restart-independent backstop now retries on its own on every service worker wake, and again the instant you open a suspended tab, so it recovers without you doing anything (#474, #397, #260). Thanks to everyone who tested pre-release builds and sent back debug reports to help pin this down.

The battery-specific timeout not reacting to unplugging​

It needed a manual trigger to take effect before; now it responds immediately when you unplug.

A bright white flash switching between suspended tabs​

Especially noticeable in dark mode. Reported as far back as v7.1.6.2 (#168), finally tracked down: a render-blocking stylesheet now paints the background immediately instead of showing the browser default until the real styles load.

The reload link on suspended tabs, too bright in dark mode​

Toned down from accent-blue to a subdued gray that actually fits the rest of that page's quiet dark-mode look.

Smaller fixes​

Tab reload/unsuspend determinism across a multi-tab selection, the debug page's tab-status list getting permanently stuck on "unknown" for a tab whose script had genuinely died, and a spacing inconsistency in Options.

What's next​

The tab-groups feature set that @mherkazandjian and, more recently, @jadshaker have been building out continues past this release: a "suspend/unsuspend all tabs not in a group" counterpart and a global "never suspend tabs in a tab group" toggle have already landed on the development branch, with a per-group override still going through review, all targeting the next release. Ukrainian was added as a supported language, with translation now underway thanks to a community volunteer. Beyond that, 9.1.0 is shaping up around wider platform reach (Edge Add-ons Store, Group Policy for managed deployments) and finer control over suspend behaviour and UI.

I wish you all the best on your journey.

Giovanni

Full changelog on GitHub: CHANGELOG.md

A few days ago, while stress-testing 9.0.3 in development with dozens of suspended tabs open and captureLogs enabled, the opposite happened: the extension itself crashed, memory exhausted, requiring a full reload to recover. That is not an acceptable outcome for a tool whose entire job is to run quietly in the background and get out of the way, let alone for an extension whose whole purpose is to lighten Chrome's memory load in the first place. What follows is the real, unedited shape of tracking that down: a first round of fixes that were genuinely necessary and genuinely not enough, followed by the investigation that found what actually needed fixing.

Starting from a real report, not a hypothesis​

That crash produced a downloaded debug log, and that log became the map for everything that followed: every fix in this post was found by tracing an actual symptom back to its cause, not by guessing at what might theoretically go wrong.

The short version of what we found first: TMS's log buffer, the piece of code responsible for collecting diagnostic entries so captureLogs reports are useful, had accumulated several real memory and correctness bugs of its own. On top of that, the debug page's own tab-status checker had a design gap that made "unknown" tab statuses effectively permanent, and a runaway event handler that could multiply its own workload without bound.

None of this affects a normal TMS install with captureLogs off. But if you are the kind of user who leaves it on to help us track down a hard-to-reproduce issue, and you run TMS the way it is meant to be run, with a lot of tabs open, these are exactly the conditions that exposed every one of these bugs. They were real, they were fixed, and, as it turned out, they were not the whole story.

Round one: the log buffer's duplicated memory, unbounded growth, and a crash under load​

TMS's gsUtils.js module is imported by every page in the extension, the background service worker, every open settings page, and, critically, every single suspended tab. Each of those contexts used to keep its own in-memory copy of the recent log history, up to 10,000 entries, even though nothing ever read that copy back except the debug page itself (which reads straight from storage instead). With fifty suspended tabs open, that is fifty redundant buffers sitting in memory for no reason. Removed entirely.

The more serious issue was what happened when the service worker briefly lost contact with a suspended tab, or vice versa, which happens routinely as Chrome recycles the service worker to save memory. A failed log delivery got queued for retry, but nothing ever capped how large that retry queue could grow. Under sustained logging with captureLogs on, that queue could grow without limit until Chrome killed the page for memory pressure, which matched the "insufficient memory, extension disabled" report almost exactly. It was capped at 5,000 entries, oldest dropped first.

Fixing that surfaced the next problem: a burst of near-simultaneous log writes, for example every suspended tab reacting at once to captureLogs being toggled, meant dozens of full-buffer read-modify-write round trips to chrome.storage.local back to back. chrome.storage.local has no append primitive, every single log entry cost a full get-parse-stringify-set of the entire stored history. With ~50 tabs open, this alone was enough to make the extension noticeably sluggish, including pages unrelated to logging that just happened to be loading at the same time. Incoming log messages were coalesced into a single merge every 250ms instead of one merge per message, turning a fifty-tab burst into one round trip.

That coalescing change itself then introduced a genuine crash: if many contexts had each queued up their own maximum backlog while the service worker was briefly unreachable, all of them flushing at once could aggregate well over 100,000 log entries into a single batch. The code merging that batch into storage used JavaScript's spread operator (array.push(...entries)) to append it, and V8 throws a hard RangeError past a few tens of thousands of spread arguments. That failure caused every sender to requeue its batch, which reproduced the exact same oversized merge on the next attempt, forever, a real, repeatable crash that lined up precisely with the original report. Switched to concat(), which has no such limit, and added a hard cap on the aggregated batch itself so it could never grow that large again.

A few more rounds of testing turned up smaller, subtler correctness issues in the same area: log ordering could get scrambled between a page's batched writes and the service worker's own immediate ones, a corrupted or malformed persisted buffer could get the retry logic stuck trying the same broken write forever, and the "Clear log" button had a narrow race where an in-flight batch could resurrect entries the user had just wiped. Each of those was closed. This whole round of fixes merged as PR #472.

The debug page: unknown status that never got better​

Separately from the log buffer, the debug page's tab profiler kept showing unknown for the status of certain tabs, indefinitely, surviving repeated manual reloads of the whole extension.

The cause: when a tab's content script genuinely stops responding (the page itself is still alive, just its script has died, a different failure mode from Chrome discarding a tab to save memory), recovering it requires TMS to re-inject and restart that script. The debug page's status check never attempted that recovery step, it did a single quick probe and gave up. Only the extension's own periodic background check ever did the real recovery work, and that check runs on its own schedule, independent of whatever the debug page happens to be showing you at the time.

The fix routed the debug page's checks through the same recovery-capable queue the background process already uses, instead of a shallow one-off probe, so a tab that needs re-injection actually gets it, and the debug page's own table now patches that row live once the real result comes back instead of leaving it stuck on a stale placeholder.

An unbounded event handler and an unbounded fan-out​

Two more issues, both specific to running with a lot of tabs open at once, also went into PR #472:

The debug page refreshes its tab table whenever the window regains focus. With no guard in place, rapid focus changes (multiple monitors, fast alt-tabbing) could trigger overlapping refreshes, each one repeating a full pass over every open tab. That was debounced to at most one refresh per second, with the in-flight run's result never silently dropped if the tab list changed while it was still running.

And the refresh itself, for every profile with more than a handful of tabs, used to fire one request per tab all at once with no cap, hundreds of simultaneous checks against the background process for a heavily-loaded profile. That was capped to a bounded number in flight at a time, spread out instead of bursting, without blocking the table from rendering while slower checks were still queued behind faster ones.

The crash that wouldn't die​

PR #472 merged. It fixed several real bugs. And going back to actually using TMS, reloading the extension, opening the debug page, browsing the tab list, it crashed again. Not eventually, not under some extreme stress test: within minutes, sometimes on nothing more than opening the debug page and looking around.

That is the point where a smaller team, or a less patient one, stops at "well, we fixed a bunch of real bugs, maybe it's better now" and ships it. We didn't, because the report was specific and reproducible, and specific reproducible reports deserve a specific reproducible answer, not a hopeful one.

The first real break came from chrome://crashes and the local Crashpad minidumps Chrome keeps on disk even after uploading them. Reading the crash annotations directly (no symbol server access needed, Crashpad embeds a surprising amount of plain-text diagnostic context in every dump) turned up two numbers that mattered: view-count/web-frame-count around 48–49, and loaded-origin-0 pointing at TMS's own extension origin. Chrome puts every page sharing the same extension origin into one renderer process: every open suspended.html, plus the debug page itself, all sharing one process, one V8 heap, with a hard ceiling around 4GB regardless of how much physical RAM the machine actually has.

That heap was nearly full: v8-oom-old-space-size (regular JS objects) sat at a tiny ~18MB, while v8-oom-memory-allocator-size (backing store for large binary buffers) was pinned near the 4GB cap. Two theories followed from that, both genuinely tested, both genuinely fixed, and neither the actual answer:

• Favicon size. gsFavicon.js built each suspended tab's favicon at the source image's native resolution before scaling anything down, and some sites serve genuinely large "favicons" (a 512×512 apple-touch-icon reused as-is is common). Capped the working canvas to a sane maximum, and, since browsers already suspended before the fix had cached the oversized version, added a version stamp so the cache silently rebuilds at the new size instead of staying oversized forever.
• The debug page's own refreshLogs(). It re-ran on every window focus event with no protection against overlapping calls, unlike the sibling function that debounces exactly this. Each run re-parsed the entire log buffer, including a full-buffer fetch that existed only to display a count. Fixed to coalesce concurrent calls into at most one in flight.

Both fixes were correct and shipped. Neither stopped the crash. The tell was in the numbers: the same ~3.7–4GB ceiling kept showing up whether 28 suspended tabs were open or 49. If either theory were the real cause, more tabs should have meant more risk. It didn't. Something else was consuming memory at a rate tied to how often the log buffer was written, not to how many tabs happened to be open at the moment of the crash.

The actual mechanism: a broadcast nobody asked for​

Static analysis of crash dumps had said everything it could. The next step was live memory profiling: chrome://inspect, attached to the shared renderer process, taking heap snapshots at intervals while reproducing the crash, saving each one to disk immediately so a mid-recording crash couldn't take the evidence down with it.

The second snapshot, taken shortly before an actual crash, showed the real shape of the problem directly: dozens of near-duplicate strings, each roughly 6MB, each a full JSON-serialized copy of the log buffer, and their timestamps were hours old. Not fresh writes accumulating under load. Frozen, historical copies of the buffer, retained since early in the session, never released.

The mechanism, once we knew what to look for: chrome.storage.onChanged fires in every context that has any listener registered for that storage area, delivering a full copy of whatever changed, regardless of whether that context's own callback cares about the specific keys involved. suspended.js registers exactly such a listener, in every single suspended tab, for one small, entirely unrelated setting. Every time anything wrote to the log buffer (which, with captureLogs on, is constantly), Chrome dutifully constructed and delivered a multi-megabyte oldValue/newValue payload to every one of those listeners, in every suspended tab, all sharing that one renderer process. None of it released once the listener finished ignoring it.

This is not a bug in the sense of a typo or an off-by-one. It is chrome.storage.onChanged behaving exactly as documented. The log buffer's design, one shared blob in chrome.storage.local, read and written across dozens of contexts, was simply the wrong shape for that API's actual delivery semantics, and the more tabs (and the more logging) a session had, the more that mismatch cost, independent of the specific favicon size or refresh cadence either earlier theory had chased.

The fix: move the whole log buffer to IndexedDB​

The whole persistence layer moved from chrome.storage.local to IndexedDB, using the same database TMS already keeps for favicon and session data. Instead of one shared blob, the log buffer is now one record per entry. IndexedDB writes have no cross-context broadcast equivalent to chrome.storage.onChanged, and per-entry records mean every context, every suspended tab included, can write directly, without funneling through the service worker as a single designated writer the way the old design required.

A good deal of complexity the old blob-based design needed went away with it: the version-token optimistic-concurrency retry loop that guarded against two writers racing on one shared value, the 250ms incoming-message coalescing window from the earlier round of fixes, and the dedicated cross-context message action that carried log entries to the service worker in the first place. None of it is needed when every writer can safely touch its own record.

What review caught along the way​

Several rounds of automated review on the migration itself caught real, live issues before they shipped:

• A write failure being reported through the same logging pipe that had just failed, which could loop indefinitely under a persistent failure (a full disk, a corrupted database) instead of backing off and retrying normally.
• Multiple contexts flushing independently meant insertion order didn't reliably match chronological order, fixed with a proper timestamp index, so "most recent" and "oldest to evict" both mean what they say.
• A multi-entry write done as separate transactions per entry, which could leave a partial batch committed and then duplicated on retry after a failure partway through, now one atomic transaction per flush.
• The "Clear log" button silently reporting success even when the underlying clear had failed.
• The one-off cleanup of the old chrome.storage.local keys, running from a place that itself ran in every context: for a profile that had already accumulated a multi-megabyte buffer under the old design, that cleanup call was itself a chrome.storage.local mutation, and would have broadcast that same oversized payload to every suspended tab one more time, on exactly the code path meant to eliminate it. Moved to run once, from the service worker only.
• Trimming the store back down to its cap, if triggered from the same per-context flush path the old design used, would let dozens of tabs each independently decide "trim needed" at once. Replaced with a single periodic chrome.alarms schedule, the same mechanism TMS already uses for backup and news-feed timing.

And a real behaviour change worth naming rather than hiding: TMS declares "incognito": "split" in its manifest, so a regular window and an incognito one run fully separate extension instances. chrome.storage.local wasn't partitioned by that split (both instances shared one buffer under the old design), but IndexedDB is. A regular debug session can no longer see what happened in an incognito window. Bridging the two isn't practical without reintroducing some form of cross-context broadcast, which is the exact mechanism this whole migration exists to eliminate, so this is accepted as a known limitation rather than worked around.

Then live testing caught one more thing none of the automated review did: after adding that new timestamp index, the log view briefly showed "No entries" while the entry counter kept climbing normally. IndexedDB only re-runs its schema-upgrade step when the requested database version number goes up: a profile that had already opened the database at its current version earlier the same day, before the index existed, never got it added. A quick version bump forced the upgrade to actually apply. A good reminder that review catches a great deal, but nothing replaces someone actually reloading the extension and using it.

A couple of other things fixed along the way​

Chasing the same crash surfaced two more issues in adjacent code, both worth a brief mention even though they're not directly about the log buffer:

A queue used for retrying tab-initialization work during startup had a subtle timing gap: a job that legitimately needed several retries (completely normal when many tabs restore at once) could end up running for minutes with the extension's own startup-completion flag stuck true the whole time, silently disabling recovery behaviour. It now has a real overall time limit alongside its existing retry-count limit, generous enough not to punish normal retries, but no longer effectively unbounded.

And a favicon-related job that starts initializing a suspended tab could keep running against a tab that had already navigated away, been discarded, or closed mid-initialization, in a few different ways depending on exactly when that happened. Each of those was closed with a shared cancellation signal that the job checks at every step, rather than a growing pile of individual point-checks that could only ever catch the specific timing gap someone happened to find.

Where this leaves things​

None of this changes what TMS does for a normal user with captureLogs off, which is the overwhelming majority of installs. What it changes is whether the diagnostic tooling itself, and the extension underneath it, can be trusted to run for an extended period, under real load, without becoming the thing you have to reload the browser to escape from. That was the actual bar for this work, and every fix above, in both rounds, was driven by hitting it, not by a checklist.

If you are running a build with captureLogs on to help track down an issue and still see something behaving oddly, please open an issue on GitHub with a downloaded debug report attached. That is exactly the workflow that made this whole investigation possible in the first place.

Why the 9.0.2 fallback still disconnected​

The fallback used chrome.identity.launchWebAuthFlow(), which on the first connection opens a real tab for you to sign in and grant access. What it returns is an implicit-flow access token, short-lived, about an hour, by design. Renewing it silently before it expires means calling launchWebAuthFlow() again with prompt: 'none', no visible tab, no interaction, just a background request that depends entirely on the browser already holding an active Google session for that tab.

That dependency is exactly where it broke. Brave and Vivaldi don't maintain that ambient session reliably the way Chrome does, so the silent renewal call would fail once the hour was up, and the account looked disconnected from TMS's side even though nothing the user did caused it.

The root cause sits upstream, in Brave's own chrome.identity implementation, not in TMS. It's tracked in brave-browser#38066, still open as of this writing, no movement from Brave's side yet. We're not waiting on it: 9.0.3 works around it entirely on our end instead.

What 9.0.3 does instead​

The fix is a proper move to authorization-code flow with PKCE. The practical difference: instead of a token that expires every hour and needs the browser's help to silently renew, one interactive consent (the same tab you already see the first time you connect) mints a long-lived refresh token, stored locally. Every renewal after that is a direct request to Google's token endpoint, no tab, no cookies, no dependency on whatever session state the browser happens to be holding onto at that moment.

This reuses the existing "Web application" OAuth client already registered for TMS (the same one used for the 9.0.2 fallback) rather than a new one. We looked at switching to a "Desktop app" client type instead, which Google documents as the more natural fit for an installed application, but tested it directly against the live authorization endpoint and confirmed it rejects the redirect URL format Chrome extensions are required to use. The existing client stays.

If you already connected Drive on Brave or Vivaldi​

There is one unavoidable step for anyone who connected Drive through the 9.0.2 fallback already: no previous release could have stored a refresh token for you, because the mechanism didn't exist yet. Once your current short-lived session expires, roughly an hour after updating to 9.0.3, the next automatic backup attempt will fail once, and TMS will show the same "Drive disconnected" indicator it already shows for any auth problem.

The fix is a single click on Connect in Options → Backup, same as reconnecting for any other reason. After that one-time reconnect, you get the new, reliable renewal path with no further action needed, indefinitely, no more surprise disconnects after a couple of backups.

The client secret: what we got wrong, and the fix​

An earlier draft of this post described shipping the OAuth client secret inside the extension package as a "known, accepted limitation", on the reasoning that a leak only lets a third party impersonate the app for a phishing consent screen, not touch any user's actual Drive data. That framing undersold the real risk.

The OAuth client TMS uses for this flow is registered as a "Web application" type, which by Google's own policy is expected to keep its client secret confidential, held server-side, never exposed. TMS has no server, so the secret was compiled straight into the extension package, and since a Chrome extension's .crx/.zip is trivially unpacked by anyone, it was effectively public the moment it shipped. The part we underweighted: this isn't just a phishing-blast-radius question, it's a policy compliance problem. Google can flag or suspend an OAuth client that doesn't meet its confidentiality expectations for its registered type, and that would break Drive backup for every TMS user at once, not just enable a narrow impersonation scenario.

We looked again at the client types Google exempts from this requirement, ones built for installed applications, like Chrome extensions, Desktop apps, iOS, and Android. Neither fits here: a "Chrome app" client only works with chrome.identity.getAuthToken(), the exact API that doesn't work on Brave and Vivaldi and is the whole reason this fallback exists, and a "Desktop app" client rejects the redirect URL format this flow has to use, confirmed directly against the live endpoint. So instead of swapping client types, we removed the need for the secret to be embedded at all.

tms-oauth-proxy is a small Cloudflare Worker, free tier (at least for now), that holds the client secret server-side and does nothing but forward the token exchange to Google: the initial authorization-code grant, and every refresh_token renewal after that. TMS's own code never has the secret at all anymore, gsBackup.js calls the worker instead of Google's token endpoint directly. The worker sees only the exchange request itself (a code or a refresh token, nothing else) and never touches your Drive data, your access token, or anything else, those stay entirely in your own browser's storage as before. As part of shipping this, the previously-exposed secret was rotated in Google Cloud Console, so the earlier one is dead regardless.

This closes the gap the original "known, accepted limitation" note left open, cleanly, for zero added cost, rather than leaving it as a documented tradeoff.

Where this leaves things​

If you're on Chrome, none of this affects you, chrome.identity.getAuthToken() already works there and this fallback never activates. If you're on Brave or Vivaldi and use Drive backup, this closes the gap that made 9.0.2's fix incomplete: one connection, one long-lived token, no more silent disconnects a couple of backups in.

Use the classic The Great Suspender artwork​

A new option in Options → General, "Use the classic The Great Suspender artwork instead of the new mascot", switches TMS's icons and illustrations back to the original The Great Suspender style, the artwork the project was originally built on, wherever a legacy version of the image exists.

It is applied consistently, not just in one corner of the UI: the toolbar icon, the suspended-tab page's favicon fallback, and every extension page's own images and favicon all switch together, resolved through a single mapping so there is no mix-and-match between old and new art on different screens. A couple of illustrations that never existed in the original set (used for less common states) have no legacy equivalent, those keep using the new artwork regardless of the toggle.

Off by default, on-demand, reversible any time. No data migration, no restart required.

Full reference in the Settings docs.

What's new​

"Always suspend" list​

A new list, right next to the whitelist in Settings, of URLs that always suspend after the normal timeout, even past the protections (pinned, audible, unsaved form input) that would otherwise keep a tab open indefinitely. Useful for something like a background Twitch or YouTube tab left playing audio that you still want suspended on schedule. Same matching rules as the whitelist (plain text or /regex/). Manual per-tab pauses and global protections (offline, charging, "never suspend") are still respected, this only overrides the passive automatic ones.

Named "always suspend" rather than "blacklist" to avoid the polarity confusion raised in the original request (#103). It also picked up its own "Test list" and "Suspend matching tabs now" buttons, mirroring the whitelist's existing test/wake pair, so you can check what matches or force an immediate suspend instead of waiting for the normal timeout.

Speaking of the whitelist: it's now called the allowlist everywhere in the UI (tooltips, popup, all 18 locales). Storage key and internal code are untouched, this was a copy pass, not a rename of the feature.

What's fixed​

Google Drive "Connect account" on Brave and Vivaldi​

chrome.identity.getAuthToken() doesn't work on either browser, for different reasons: Brave attaches a custom URI scheme Google's backend rejects outright and shows a raw Error 400: invalid_request page; Vivaldi disables Google sign-in entirely, so the callback just never fires and the connect flow hangs with no feedback. TMS now falls back to chrome.identity.launchWebAuthFlow(), races the original method against a timeout so a Vivaldi-style hang surfaces as a failure instead of hanging forever, and remembers which method worked per install so later calls skip straight to it (#420).

Suspended tabs stuck with the default favicon after a restart​

The startup check that repairs favicons and titles only ran from events some Chromium builds (notably Brave) never fire after a normal restart, leaving suspended tabs stuck with the generic icon until clicked. A storage-based sentinel now catches this on every service worker wake instead (#397). Thanks to @pbc-commits for the investigation and root-cause writeup.

"Allow access to file URLs" toggle missing​

Chrome only shows this toggle when the manifest declares file:// host access, which TMS never did. Added as an optional host permission, on-demand like downloads/identity, no access granted until you flip it yourself (#393, #416, #267).

Suspended page waited on the hotkey label before becoming clickable​

Restoring a suspended tab was gated behind a chrome.commands.getAll() call to fetch the shortcut-key label for display, purely cosmetic, but slow enough to make the click handler feel unresponsive. The page now becomes interactive first and fills in the hotkey label after (#320).

"Claim by default" option​

Shortened the option label and moved its explanation into a tooltip instead of a long parenthetical (#151), then reworded again after that first pass still left it meaningless without opening the tooltip: it's now "Claim tabs suspended by other extensions", says what it does without requiring a hover.

Manual backup cooldown had a hole in it​

The 30-second cooldown after a manual "Backup now" was only ever enforced as a per-page debounce local to the Backup page's own button. The popup has its own "Backup now" menu item, with no cooldown and no shared state with the page, so triggering from both let you fire off backups back-to-back. The cooldown now lives in gsBackup.performManualBackup() itself, tracked in session storage so it's enforced no matter which UI triggers it; the popup shows a live countdown and disables the item if a cooldown from the other surface is already running.

"Always suspend" list showing a literal "undefined"​

Ironic given this ships in the same release that introduced the list: upgrading from an install that predates it left the textarea showing the literal word "undefined" instead of being empty, because settings only got backfilled with new defaults on a brand-new install, not on existing ones. Settings now backfill any missing keys on every load, not just first run.

Locale drift closed​

A source-string edit had quietly broken Crowdin's fuzzy match on 7 strings, reverting them to English across all 16 non-English/Italian locales, on top of a handful of genuinely new keys. Both are fixed and locales are back in sync. Added scripts/check-locales.js (npm run check-locales) so this kind of drift is caught locally before it ships, not the fix itself, but worth having.

Also in this release​

A handful of smaller things that don't need their own section:

• Bulk-delete Drive backups per device. The Backup page already grouped Drive files by device when more than one machine backs up to the same account, but clearing out one device's files meant deleting them one by one. A "Delete all" button next to each device's group heading now handles it in one go, with the same confirm-before-delete modal as single-file deletes.
• Extension description reworded to match the tone used everywhere else TMS is described: "Free your memory. Suspend the tabs you don't need, right now."
• The Backup page now shows which Drive OAuth method is active for the install (getAuthToken vs. the launchWebAuthFlow fallback from above), as a quiet second line under the "TMS Backups" folder name, mainly useful for support.

The bigger job: triaging the whole backlog​

9.0.2 was the small part of today's work. The real effort went into going through every open issue on the tracker, 56 of them, most untouched for months, and sorting each one into an actual plan instead of a flat list.

The outcome: 31 issues now sit in a concrete milestone (9.0.2, 9.0.3, 9.1.0, 9.2.0, or 10.0.0), scoped by what they actually need, a quick fix, a real feature, or a design spike, rather than by how old they are. The remaining 25 are genuinely unclear: duplicates to merge, reports that need reproduction steps, or requests that need a decision before they can be scoped at all, and they'll get worked through the same way.

The other side of a release: reviews and inbox​

Version 9 and its two bugfix releases were rolled out alongside a redesign, changes to permissions, and a new backup feature, and the reviews posted since then on the Chrome Web Store have made it clear that there are a lot of new features to take in all at once in a single update—and, to be honest, we were somewhat expecting this, though perhaps we hadn't factored in the "unwarranted hostility" that is often part of the game in the open-source world (and this is certainly no excuse, because respect, empathy, and tact always come first). It's worth examining them carefully, rather than simply highlighting only the positive aspects (which, fortunately, are there as well).

"Why does it need all these permissions now?"​

This was the loudest thread, a run of 1-star reviews within hours of each other listing the new permission prompt verbatim: "Read and change all your data on all websites," "Read and change your browsing history on all your signed-in devices," "Manage your downloads," "View and manage your tab groups". Read cold, with no context, that's a reasonable thing to be alarmed by. One reviewer put it plainly:

"Now, the app itself is wonderful, but I am fearful about saying yes to so many permissions. [...] Message to the Devs: please provide an explanatory blog post on why you need so many permissions. I will happily update this to 5* if the reasons are convincing".

The post already exists, the 9.0 permissions FAQ, and explains each permission against the feature that needs it (downloads for local backup, identity for Drive backup, the broad host permissions for the scripting-based form/scroll detection that predates 9.0). The problem is it was never linked from the Chrome Web Store update notes, so nobody hit it unless they went looking, and one reviewer said as much ("Looks like all the permissions are legitimate. But in the update notice, I didn't see this link"). That's on us, not on the reviewers: the explanation being technically correct and effectively invisible is the same as not having written it. The CWS listing will link it directly going forward.

The generative-image backlash​

The new suspended-tab illustration set uses AI-generated art, and the reaction has been unambiguous and consistent, from a 1-star review ("So now I am forced to see garbage genAI images on every suspended tab?"), to a Chinese-language review calling the new icon 丑爆了 (bluntly, "hideously ugly"), to a calm, direct email from a long-time user asking us to either revert to the old artwork or commission an actual illustrator, because shipping AI art "will make it appear cheap and rushed to the users who don't see all the code and scripts you designed for it". That last framing is the one worth sitting with: it's not really about the pixels, it's about what the choice signals for a project that otherwise puts real engineering effort into every release. This is going back into discussion, no decision made here, but the signal is too consistent across independent channels to wave off as noise.

"Stop changing the UI"​

A smaller but genuine thread: the redesign changed the suspended-tab screen and, more concretely, removed a state cue some users relied on daily, the toolbar icon used to visibly change when a tab was paused from suspension, now you have to click it to check. One review called this out at length, and re-submitted the same text three times over two days, which reads less like spam and more like someone who really wanted it seen. That one is a legitimate regression report, not a taste complaint, and it's going on the backlog to fix, not just to note.

Real bugs found in the noise​

Sorting the sharp tone from the substance, three reports didn't match anything already tracked and got opened as issues today:

• #426: a user reported the extension's settings page and keyboard shortcuts becoming unavailable entirely after updating, no repro yet, but too specific to dismiss.
• #427: automatic local backup apparently writing outside the configured tms-backups folder, with filenames drifting to Chrome's own download.json, download.json (1), (2)... pattern and the configured file-count limit being ignored.
• #428: a report that recent updates broke Gmail's own delete/move actions, symptoms that don't persist until a manual refresh. Needs isolating, but too precise a description to be a red herring.

A fourth pattern, suspended tabs vanishing without a trace after a crash, showed up again in this batch too, but that one's not new: it matches #396 and #402, already on the board.

On the tone​

Some of these criticisms were quite harsh. "Shameful", "crazy", "a terrible, truly terrible change", it's really a lot to read all at once, and a couple of reviews were clearly emotional outbursts rather than concrete reports. That's fine; that's what the reviews section is for, and it doesn't change how the actual bugs mentioned above are handled. But it's also worth stating clearly that the never-out-of-style tactic of posting a barrage of very negative reviews immediately after a release that simultaneously changed permissions, graphics, and the user interface is, in itself, a sign: bundling so many visible changes into a single update has made it much harder for anyone to distinguish at first glance between "this is a real problem" and "this is different, and I don't like the difference".
Change is always scary. This is a lesson on the order of changes to keep in mind for future updates, as well as for this specific case.

Comments are now open on the KB​

Speaking of feedback: every post on the Marvellous Codeworks KB, this one included, now has a comment section right at the bottom. No Chrome Web Store review box, no GitHub account required. If you've got a bug report, a question, or an opinion on any of the above, that's the place for it now, we'll be reading.

What's next, concretely​

• 9.0.3: right after this release, already-scoped quick wins, default branch rename (master to main), a favicon-cleanup follow-up, a handful of small long-standing UX requests, plus one item needing a feasibility spike before work starts, a battery/charging-aware suspend timeout.
• 9.1.0: platform reach, an Edge Add-ons Store listing and Group Policy support for managed deployments, plus standalone improvements: a pause button, staggered session restore (so restoring 40 tabs at once doesn't hammer the browser), and a rework of the YouTube screenshot capture path.
• 9.2.0: a Session Manager rework, collapsing/reordering windows, deleting a single window without touching the rest, bulk export, plus lifecycle settings like auto-unsuspend on restart, auto-cleanup of old sessions, and an option to disable session tracking entirely.
• 10.0.0: no near-term date, this is where larger architecture-level changes land, per-tab-group settings is the first candidate.

None of this is set in stone, milestones will keep shifting as issues get re-scoped, but there's now an actual sequence instead of one long undifferentiated backlog.

I wish you all the best on your journey.

Giovanni

Full changelog on GitHub: v9.0.2 release

Permissions are now on demand, not upfront​

This is the headline change. In 9.0.0, downloads and identity were declared as regular permissions, so Chrome asked for both the moment you updated, whether or not you ever touched the backup feature. That's exactly what triggered the disable-and-reprompt dialog most of you saw, and exactly what issue #411 called out as "substantially overprivileged for users who do not use backups."

Starting with 9.0.1:

• downloads is only requested the moment you toggle Enable automatic backup on, in Backup & Sync. Leave it off, and TMS never asks.
• identity is only requested when you click Connect to link a Google account for Drive backup. Never click it, and TMS never asks.

If you already had backup enabled under 9.0.0, you won't see anything new, Chrome keeps permissions you already granted when a later update moves them from required to optional. No re-prompt, nothing to redo.

Full breakdown on the permissions page.

A quieter way to be reminded backup exists​

Session backup is still, by a wide margin, the most requested feature TMS has ever shipped, and the vast majority of you haven't turned it on yet. Rather than push harder, 9.0.1 adds a deliberately low-key nudge: a small amber badge on the toolbar icon, a banner in the popup, and a note on the Backup & Sync page, all pointing at the same place, all easy to dismiss.

Remind me in 10 days snoozes it. A permanent I'm not interested, stop reminding me checkbox on the Backup & Sync page turns it off entirely. No pop-ups, no repeated interruptions, just a quiet signal that stays out of your way once you've told it to.

News feed opt-out​

The daily background check against marvellouscode.works for TMS-related posts (feeding the in-extension News page) had no way to turn off. It does now: Enable news feed in Settings → General, on by default. Turn it off and the fetch alarm is cleared immediately, along with the News entry in the sidebar.

The Drive-only local file, explained​

If your backup destination is Google Drive but you still occasionally see a file appear in your Downloads folder, that's not a bug. On browser shutdown, TMS always writes a local safety-net copy first, a Drive upload isn't reliable in that narrow shutdown window, so the file gets queued and uploaded on the next startup instead, then cleaned up automatically once that upload succeeds. This was true since 9.0.0 but never explained anywhere in the UI, issue #411 was right to flag it. It's now spelled out directly on the Backup & Sync page.

In-app permissions transparency​

Two smaller, related additions: a one-time banner on the Settings and Backup & Sync pages explaining the permissions change above (with a link to the docs), and a persistent reference note on the Backup & Sync page for anyone who lands there later and wants the short version without digging through a blog archive. Going forward, this is where permission changes get explained, not just here.

What we're not doing​

Backup content encryption came up as a suggestion in issue #411 too. We're not adding it, not in 9.0.1 and not planning to. Backup files carry the same level of protection the manual "Export session" feature has had since 2017 (plain JSON, no encryption), nothing on your machine or your own Drive appdata folder is exposed to anyone else by that choice, and we'd rather keep the feature simple than bolt on a passphrase system nobody asked for twice.

Thanks​

To everyone who pushed back on 9.0.0's permission model instead of just uninstalling and moving on: this release exists because you took the time to write it up instead. That's the whole reason issue #411 got a direct answer instead of a shrug, and it's why the fix landed this fast.

If something's still off, open an issue or use the report form. We read all of it.

Full changelog on GitHub: v9.0.1 release

If you saw this dialog, Chrome disabled TMS on update and is asking you to confirm the new permissions before turning it back on. That's expected, and it's Chrome doing its job. Here's why each one is there, and what to do if you'd rather not grant all of them.

Why the new permissions​

Two of the permissions listed, downloads and identity, are new in 9.x. Both exist for exactly one feature: session backup, the single most requested thing in TMS's entire history, now finally shipped, either to a local folder or to your own Google Drive.

• downloads lets TMS write backup files to a tms-backups/ folder inside your Downloads, and clean up old ones automatically. TMS never reads anything in your Downloads folder beyond the files it wrote itself.
• identity is used only if you choose Google Drive as your backup destination. It gets an OAuth token to talk to Drive, TMS never sees your Google password, and the token exchange is handled entirely by Chrome.
• The Drive backup, if enabled, is scoped to drive.appdata, a hidden, app-only folder that isn't visible in your regular Drive and isn't reachable by any other app.

Full breakdown, including exactly what changed since 8.x, is on the permissions page.

The important part: both permissions sit dormant until you actually turn on automatic backups in Backup & Sync. If you never enable that feature, TMS requests no Drive authentication and writes nothing to Downloads. We're aware that Chrome asks for the permission up front regardless, at install/update time, not at first use, which is exactly the kind of thing that reads as scarier than it is. We hear that, and we're working on a setting to opt out of backups and their reminders entirely, which should let us drop these permissions for anyone who doesn't want the feature. That's not shipped yet, it's actively in progress, and we'll cover it here once it lands.

The deeper questions, and what's landing in 9.0.1​

Issue #411 went further than "why the new permissions," with some sharper technical points worth answering here too, not just in a GitHub thread:

• downloads is requested unconditionally, even if you never enable local backup. Fair. It's a static manifest permission right now instead of one requested at runtime when you actually turn on local auto-backup. Moving it to on-demand is going into 9.0.1, so most people who don't use backups won't see this prompt at all.
• Backup files are plain JSON, and base64 isn't encryption. Correct, base64 there only builds a data: URL so a service worker can hand the file to chrome.downloads.download() (blob URLs don't survive service worker restarts), it was never meant as protection. Worth noting: it's the same level of protection the manual "Export session" feature has had since 2017, so this isn't a new risk 9.0.0 introduced. Optional passphrase encryption for backup content is a reasonable ask and it's on the list.
• A Drive-only configuration can still write a local file. Also correct. On browser shutdown, TMS runs an emergency backup that always writes locally first, because a Drive upload in that shutdown window isn't reliable, the service worker can get killed mid-request. If your destination is Drive, that file gets queued and uploaded on next startup. A deliberate reliability trade-off, but not currently explained anywhere in the UI. That's getting a note, plus cleanup of the local copy once the queued Drive upload succeeds.
• A daily request to kb.marvellouscode.works/blog/rss.xml. Yes, an alarm every 24h feeding the sidebar News page. The host is already declared in the manifest, nothing hidden, but there's no way to turn it off today. A toggle is coming.

One more thing worth admitting straight: the permissions page and the posts covering this were published before 9.0.0 went live, but nowhere the extension itself points to them. That's the actual gap, not the timing. Going forward, whenever a release changes permissions, the options page and changelog will link directly to what changed and why, instead of relying on people finding the blog on their own.

None of this changes what TMS does with your data today, nothing leaves your machine except to your own Drive appdata folder, but the scoping and the missing opt-outs were legitimate gaps, and 9.0.1 is where they get closed.

"It requires too many permissions now, wtf?"​

Fair reaction from the outside, and exactly why the section above exists. Short version: nothing new is silently collecting or shipping your data anywhere. tabs, storage, history, contextMenus, alarms, favicon, scripting, and tabGroups were all already there in 8.x, doing the same jobs they always did. downloads and identity are the two genuinely new ones, and they only exist because of the backup feature described above.

"Major updates too frequently cause suspended web pages to disappear. Please do not always change how the UI looks."​

Two separate points here, and we want to be honest about both.

On the UI: yes, TMS 9 changed how every settings page looks. That was intentional and covered at length in the launch post, it needed doing, but we know it's disruptive and we're not planning another full repaint anytime soon.

On suspended pages disappearing during updates: that one worries us more, because it shouldn't happen from a TMS update alone, and it's worth separating from a specific incident we're actively helping someone recover from right now.

When sessions actually vanish, it's usually not the update itself​

We got a report of exactly this, sessions gone after an update, and dug into it in issue #410. TMS pins a fixed extension ID in its manifest, so a normal update should never touch your saved sessions in chrome.storage/IndexedDB, they live at that same ID before and after.

What we found instead: Chrome occasionally flags an extension as "corrupted" after an update and offers a repair/reinstall flow, and that repair flow can reset the extension's local storage even though the ID doesn't change. That's a Chrome-side quirk, not something TMS's update logic triggers. Cold comfort if it happens to you, we know, so if you ever hit it:

1. Check the extension's History/Manage Sessions page and the Recovery page first, sometimes the data is still there and just needs a poke.
2. Compare the extension ID in chrome://extensions (Developer mode on) against your backed-up IndexedDB folder name, if you have one.
3. If you have a raw IndexedDB backup, tab URLs are recoverable as plain text even from the binary .ldb/.log files, full recovery steps are in the issue thread.

If this happens to you, open an issue (or use the no-account report form) with what you're seeing, we'll walk through recovery with you the same way.

We read everything​

As said before, we mean it: reviews, star ratings, GitHub issues, all of it gets read, and this post exists because of exactly that. If something about TMS 9 is bothering you, permissions, the redesign, anything else, open an issue or use the report form. We'd rather answer it directly than have it sit in a star rating we can't reply to.

It's also pushing about 40°C outside as we write this, summer in full swing, and yes, 40°C in Italy is exactly as absurd as it sounds. Wherever you are, we hope you get a good stretch of vacation out of it. We won't really be taking one ourselves, but we'll admit to easing off the throttle a little.

What actually shipped​

• Session backup and restore (arguably the single most requested feature, since the dawn of time), local or Google Drive, on a schedule or on demand, multi-device aware.
• A Tab Health page that scans your suspended tabs and repairs the Tab Groups restart bug on Chrome, Edge, and Brave with one click (the underlying bug is fixed now, but we kept the tooling around and available on demand, just in case).
• A News feed that pulls straight from this blog into the extension's sidebar.
• A visual redesign that finally makes every settings page look like it belongs to the same product.
• Sixteen languages brought back up to parity after being left behind for who knows how long.

None of that happened in a straight line, and none of it happened alone.

The chats with Rob​

Rob and I don't work in the same office, the same country, or even close to the same timezone half the time. Most of TMS 9 got decided in a Slack channel, at hours that made sense for neither of us, arguing about whether a permission scope was too aggressive, whether a setting needed a tooltip, whether "Restore from backup" should live under Sessions or Backup. Small questions, but the kind that decide whether an extension feels considered or just shipped.

The Great-er Tab Discarder (TGD) and The Marvellous Suspender (TMS) are separate projects with separate codebases, but Marvellous Codeworks only works because there are two of us pulling in the same direction, checking each other's blind spots, and occasionally telling the other one an idea is bad before it ships. TMS 9 is better for it, and we hope to do the same for TGD soon.

The community that showed up​

TMS 9 also has two first-time contributors in the changelog: @MatrixNeoKozak, who refactored the storage layer to drop unnecessary JSON serialization, and @iGhost, who added the option to preserve YouTube playback position on suspend, a small feature, requested and built by someone who actually hit the problem (something I never personally needed, for what it's worth). That is exactly how an open-source project is supposed to grow: not just bug reports, but pull requests from people who decided to fix the thing themselves.

On top of that, sixteen locales got AI-assisted translation passes to close gaps that had been sitting there for versions (Claude had free rein here). They are not perfect. If you read TMS in your language and something sounds off, Crowdin is open and corrections from native speakers are exactly what closes that gap for good.

Reporting an issue without a GitHub account​

For years, the only way to tell us something was broken was to open a GitHub issue, which meant a GitHub account, which meant a wall a lot of people simply weren't willing to climb over just to report a bug. We kept hearing about problems secondhand, in reviews, in Reddit threads, never where we could actually act on them.

marvellouscode.works/tms/report aims to fix that. Fill in a form, no sign-up, no account, and it opens a proper GitHub issue on your behalf, correctly labeled, with the fields we actually need to reproduce the problem. You get a status link back to follow along, we get a real, actionable report instead of a one-star review that just says "stopped working."

And on that note: we do read everything, including what shows up directly on the Chrome Web Store. Star ratings, written reviews, support requests left in that little review box, all of it gets read. We keep an eye on GitHub Issues specifically because that is where we actually track and act on things, verifying odd behavior, following up on requests, closing things out once they're fixed, but a review left on the Store is not shouting into a void either.

A documentation site built from scratch​

The old TMS wiki lived on the GitHub repo, half-finished, out of date in places, and honestly not the kind of thing you'd send someone to if you wanted them to actually understand the extension. It's disabled now.

In its place: kb.marvellouscode.works/docs, built from the ground up on Docusaurus, page by page, primarily for TMS 9 (though really designed to cover everything that ends up under the Marvellous Codeworks umbrella). Every settings page has its own article, Settings, Sessions, Backup, Tab Health, Quick Actions, Keyboard Shortcuts, News, About, explaining what every toggle actually does, not just what it's labeled. There's a dedicated page on permissions, spelling out why TMS asks for what it asks for, and what changed with the narrower Drive scope in this release. FAQ included. Nothing hidden in a stale wiki page nobody updated since 2019.

We built it, page by page, deciding what actually needed explaining versus what was obvious enough to skip. The marvellouscode.works domain has actually been sitting registered for almost a year now, it just took weeks and weeks of actual writing, restructuring, and rewriting to turn it into the site, the docs, and the report flow you can use today.

Everything changes. Nothing changes.​

TMS 9 looks different, is organized differently, backs itself up differently, and speaks more languages correctly than it used to. That is the "everything changes" part, and it took a full rewrite of the settings pages, a new backup system, and a lot of late chats with Rob to get there.

The "nothing changes" part is simpler: TMS still exists to take tabs your browser is hoarding in memory and put them to sleep until you actually need them again. That was true the day The Great Suspender got rescued, it was true through the Manifest V3 rewrite, and it is still true in v9.0.0. Every feature in this release, Tab Health, backups, the redesign, exists to protect that one job, not to replace it.

Not everyone will love it, and that's fine​

We're perfectly aware that not everyone is going to be thrilled with the new look. Change is rarely comfortable, and a redesign this size, new fonts, new colors, new layout on every single page, is exactly the kind of thing some people will need time to get used to, or just won't like at all. That's part of growing a project, it's part of the deal.

We still believe the repaint was necessary, and we think it's only the first big step. There are more ideas in the pipeline, and there are plenty of problems and feature requests already sitting in GitHub Issues that we intend to work through to keep pushing TMS forward. We're listening, we take feedback and constructive criticism seriously, that's the whole point of open source in the first place.

What's next​

Google's review is done, the changelog is final, and the rollout starts Monday morning, August 3rd. Chrome Web Store updates roll out gradually rather than to everyone at once, so don't panic if you don't see v9.0.0 the second you check, it'll reach you within the normal update window. This series is officially done. Thank you for reading along the whole way, for testing feature branches, for opening issues, for the pull requests, and for the patience.

See you on the other side, in v9.0.0.

This week we actually ran that repair on a Brave profile with tab groups in a broken state, and it is worth showing rather than just describing.

Scan Tabs​

The Tab Health page opens with a single button. Nothing happens until you ask for it.

What the scan found​

Clicking Scan Tabs walks through every tab and reports back. On this Brave profile, out of 28 tabs, TMS found 5 suspended tabs, 20 cached favicons, and 21 grouped tabs in a broken state, flagged specifically as the Tab Groups bug.

That number is the point of this post. On Brave, those 21 tabs would otherwise sit there as blank chrome://newtab/ pages until someone clicked the browser Back button on each one, one at a time. Instead, a Repair 21 grouped tab(s) button appears right below the scan results.

One click later: "Restoring favicons... 21 tabs. Done. Re-scan to verify grouped tabs are back to their suspended state." All 21 tabs recovered in a single pass, matched back to their original suspended URLs by window order and tab index, the Brave-specific recovery path described in the Chrome 150 post.

Why this matters for Brave users specifically​

Chrome shipped the real fix in version 150. Whether and when Brave aligns with it is out of our hands, Brave tracks upstream Chromium on its own schedule, and there is no guarantee it lands quickly. If it does, this repair simply becomes unnecessary, the same way it already is for Chrome 150 users.

If it does not, TMS 9 gives Brave users a real answer instead of a manual workaround: open the Tab Health page, click Scan Tabs, and if it finds broken grouped tabs, click Repair. No side-loaded companion extension, no clicking Back on every tab, no waiting on a browser vendor's release notes.

It is now here. Chrome 150.0.7871.47 ships the browser-side patch for crbug.com/522338670. Tab groups restore correctly without any intervention from TMS. We have verified this with a clean restart session and multiple group configurations, and everything behaves as expected.

Here is what that means for TMS, and what we decided to do with the workaround code.

What we removed from the startup path​

The TMS 8.1.4 workaround lived entirely in the extension's startup sequence. Every time the browser launched, TMS would:

1. Scan all tabs and cache suspended URLs for grouped tabs as Chrome assigned group IDs.
2. Detect grouped suspended tabs that Chrome marked as discarded before the user could click them.
3. Re-create those tabs in-place, restore their group membership, and remove the broken originals.
4. Handle late onReplaced events that fired after the startup window closed (the Chrome and Edge variant of the bug).
5. For Brave, which doesn't fire onReplaced at all, match broken chrome://newtab/ grouped tabs against the last saved session by window order and tab index, then recreate them.

With Chrome 150 restoring grouped tabs correctly, all of this runs for nothing on every single startup. Worse, if Chrome and TMS both try to recreate the same tab, the interaction is unpredictable. So we disabled the entire startup path.

The code is still there, commented out in gsSession.js and background.js, clearly marked with // DISABLED FOR TESTING: Chrome 150 Tab Groups fix. If a future Chrome update regresses this behavior, re-enabling it takes minutes.

What we kept, and where​

Disabling startup recovery does not mean abandoning users who hit broken grouped tabs. It means moving the recovery to the right place: the Tab Health page.

The Tab Health page (health.html) is TMS's existing on-demand diagnostic tool. You open it, click Scan Tabs, and TMS checks your suspended tabs for issues, missing favicons, stale cache entries, tabs that haven't fully loaded. It reports what it finds and offers a targeted action to fix it.

We added a new check to this scan: grouped tabs in broken state. The scan now detects two failure modes:

• Chrome / Edge path: a grouped suspended tab is in a discarded state. This means Chrome started the session restore but did not complete it correctly, leaving the tab with its suspended URL intact but inactive. TMS can re-create the tab in-place, restore its group, and remove the broken copy, without the user having to click anything manually.
• Brave path: a grouped tab is showing chrome://newtab/ instead of any content. Brave does not fire the onReplaced events that Chrome and Edge use, so the broken URL is gone. TMS recovers the suspended URL by matching the tab's position (window order and tab index) against the last saved session.

If the scan finds zero broken grouped tabs, which will be the case for every Chrome 150+ user, it shows 0 ✓ and moves on. If it finds any, a Repair grouped tab(s) button appears as the first action, above the existing favicon checks, because a structurally broken tab is a more urgent problem than a missing favicon.

The recovery logic itself is identical to what the startup path used. It is just no longer running automatically on every launch.

Why this split makes sense​

The startup workaround had to be aggressive by design: it ran before the user could interact with any tab, because a single click on a broken grouped tab in Chrome's session restore was enough to lose the suspended URL permanently. That aggression was justified when the bug was active. Now that Chrome fixes it natively, running the same code at startup becomes unnecessary noise, and potentially a source of conflicts if Chrome's own restore logic and TMS's recreate logic both fire on the same tab.

Moving recovery to the health page shifts it from "runs automatically every time, no matter what" to "runs when the user explicitly asks." That is the right model for a workaround that is no longer expected to be needed.

The event-driven handlers, the ones that hooked into onReplaced and onUpdated during the startup window, cannot be replicated outside the startup context, so those remain commented out in the background script. They are not lost; they are preserved exactly where they need to be if we ever want to reactivate them.

For Brave and Edge users​

The browser-side fix shipped in Chrome 150. Brave and Edge follow their own Chromium release schedules, so the patch may arrive at different times for those browsers.

• Brave users: the Brave path in the health page recovery remains active and will work on any Brave version. If you restart Brave and notice grouped tabs showing as new tabs, open the Tab Health page and run a scan.
• Edge users: Edge 149+ has shown symptoms of the same regression. Once the Chromium 150 patch reaches Edge's stable channel, you will be in the same position as Chrome users today. Until then, the health page recovery is available if you need it.

We hope the other Chromium-based browsers catch up with this fix quickly. But if they don't, once TMS 9 is available you will be able to rely on the new Tab Health page recovery to fix broken grouped tabs on demand, without waiting for a browser-side patch.

Summary​

If you are on Chrome 150 and everything is working: nothing to do. If you ever hit broken grouped tabs again, on any browser, open the Tab Health page and let TMS sort it out.

Related posts: TMS & Chrome 149: the original bug report · TMS & Microsoft Edge: the Chromium regression hits Edge too

GitHub issues: #369 · #374

What is a "third-party library" and why should you care?​

TMS is not written from scratch. Like most software, it relies on a handful of external libraries, small pieces of code written by other developers that handle specific tasks so we do not have to reinvent the wheel. These libraries live inside the extension you install, and their health matters: an abandoned library means bugs get no fixes, known vulnerabilities go unpatched, and compatibility with future browser versions is not guaranteed.

Until now, TMS included two such libraries that were overdue for attention.

db.js: a quietly abandoned dependency​

db.js, written by Aaron Powell, is a small wrapper around the browser's IndexedDB storage engine. TMS uses IndexedDB to remember your suspended tabs, saved sessions, favicons, and screenshot previews. db.js was responsible for every read, write, and query against that database.

The problem: development on db.js effectively stopped in 2021. The npm package has been frozen at version 0.15.0 for years. No bug fixes, no security patches, no updates for changes in browser behavior. We were shipping dead code, and dead code carries risk.

We replaced db.js with idb, the IndexedDB wrapper maintained by Jake Archibald (a Google engineer who literally helped write the browser storage specs). idb is:

• Actively maintained, currently at version 8
• Widely used across the web platform ecosystem
• Lean, well-tested, and licensed under ISC (permissive open source)

From your perspective as a user, nothing changes. Your sessions, your suspended tabs, your settings, all of it is stored the same way in IndexedDB. The only difference is that the code that reads and writes your data is now backed by a healthy, modern library instead of an abandoned one.

html2canvas: from a 2020 release candidate to a stable release​

The second change is smaller in scope but still worth mentioning. html2canvas, the library TMS uses to generate the screenshot preview shown on suspended tab pages, was pinned at version 1.0.0-rc.7, a release candidate from 2020. We were shipping pre-release software to everyone.

The library's author, Niklas von Hertzen, published the stable 1.4.1 release in 2022. This version includes several rendering fixes, better SVG support, and improved CORS handling. We updated to it.

For users who have the screenshot preview feature enabled in TMS settings, this may result in slightly more accurate previews on complex pages. For everyone else, there is no visible difference.

An open question for the community: do you use full-page screenshots?​

Here is where we need your input.

The screenshot preview in TMS has two modes, configurable in Settings → Preview:

• Viewport: captures only the visible portion of the page when you suspend it.
• Full page: scrolls and renders the entire page content, even below the fold.

html2canvas is the only reason TMS needs to ship a 200 KB library. The viewport mode does not actually need it at all, Chrome provides a native API (chrome.tabs.captureVisibleTab) that captures the visible area of a tab directly from the extension, with no third-party code required. Full-page screenshots, however, need html2canvas because no native browser API supports them.

So the question is: do you actually use full-page screenshots? If the vast majority of users either have previews disabled or use viewport-only mode, we could remove html2canvas entirely in a future release, replacing the viewport capture with the native Chrome API and dropping full-page support. The result would be a smaller, simpler, more maintainable extension.

We have opened a discussion on GitHub for exactly this:

👉 Discussion #381, Which screenshot preview mode do you use in TMS?

If you have an opinion, whether you love the full-page preview or have never even turned it on, we would genuinely like to hear it. Community input is what drives these decisions.

Summary​

These changes will ship in the next TMS release. If you encounter any regressions with session storage, tab history, or screenshot previews after updating, please open an issue on GitHub.

Thank you for using TMS, and thank you, as always, for the patience you extend to a small team maintaining this project in their free time.

The feature/session-backup branch changes that.

Automatic session backup​

The headline feature is a new background module, gsBackup.js, that silently saves your current session as a JSON file on a schedule you control. No dialog, no confirmation prompt, no interruption. It just runs.

You configure it from the new dedicated Backup page (more on that below):

• Interval: 15 minutes, 30 minutes, 1 h, 2 h, 4 h, 8 h, or once a day at a specific time you choose.
• Destination: your local Downloads folder (inside a tms-backups/ subfolder) or your Google Drive.
• TMS retains the 10 most recent backups and automatically deletes older ones. No manual cleanup needed.

One detail worth calling out: backup alarms are now anchored to real clock time, not to browser startup. If you set a 15-minute interval, backups always fire at :00, :15, :30, :45, regardless of when you started Chrome. The daily option lets you pick a specific time of day; it will fire at that time every day, even if you restart the browser in between.

A "Backup now" button is also available directly in the popup when backup is enabled, so you can trigger an immediate save without opening the Backup page.

Google Drive integration​

When you choose Drive as your destination, TMS authenticates silently via Chrome's identity API (OAuth 2.0, drive.file scope, access limited to files TMS itself creates) and uploads each backup to a visible "TMS Backups" folder in your Drive. Cleanup of old Drive backups (keeping the 10 most recent) is handled automatically, just like local backups.

If a scheduled backup fires while no Google account is connected, or if the token expires, TMS shows a red badge on the extension icon and a banner in the popup the next time you open it, so you notice the problem before you actually need a backup.

A dedicated Backup page​

Previously, backup settings were buried at the bottom of the Options page. In TMS 9 they get their own first-class page, accessible directly from the sidebar on every settings screen.

The Backup page has two clear sections:

• Settings backup: export your extension settings to tms-settings.json, or import a previously saved file to restore them. The file is always overwritten on export, settings are not versioned, they are a single point-in-time snapshot. Useful after a reinstall, a machine migration, or just as a safety net before experimenting with settings. When Drive is connected, a "Save settings to Drive" button also appears here, uploading the same file to your TMS Backups folder.
• Automatic session backup: the interval, destination, and Drive account controls described above.

Wake whitelisted tabs​

A smaller but handy addition: a new "Wake whitelisted tabs" action finds every suspended tab whose original URL matches your whitelist and unsuspends them all in one shot. It appears in the popup (below "Unsuspend all tabs") and next to the "Test whitelist" link in Options. If you regularly whitelist certain domains but sometimes find them suspended after a restart, this is the button you've been waiting for.

Diagnostic page overhaul​

This one is more for power users and anyone who has ever had to file a bug report.

TMS's old debug page was effectively read-only and required DevTools access to extract anything useful. The redesigned Diagnostic page has a proper log viewer (colour-coded by level), a persistent log buffer that survives Service Worker restarts, and three action buttons: Refresh, Clear log, and Copy/Download report.

The downloadable report bundles the extension version, browser user-agent, a tab profiler snapshot, and the full log buffer into a single shareable text file. If you encounter a bug and open an issue on GitHub, this report gives us everything we need to diagnose it, no DevTools required on your end.

The "Capture verbose logs" toggle now persists to storage and wakes the Service Worker immediately when changed, so you don't need to restart Chrome to start capturing.

Bug fixes in this branch​

Three fixes that ship alongside the new features:

Grouped suspended tabs lost after Chrome restart. Chrome 149 introduced a bug (crbug.com/522338670) where tabs inside tab groups with non-https:// URLs, including TMS suspended tabs, could be navigated to chrome://newtab/ instead of being restored. TMS 8.1.4 already included a partial fix; this branch extends it: if the reinitialisation check detects that a suspended tab in a group has been navigated away, TMS creates a fresh tab with the correct suspended URL, places it back in the same group, and removes the broken one. No more "press Back to recover" workaround.

Extension's own pages treated as regular tabs. TMS's internal pages (options.html, about.html, debug.html, etc.) were not matched by the isBrowserInternalURL check, which tested for chrome: but not chrome-extension://, so they could end up in the suspension queue and generate repeated failed content-script injection attempts. A dedicated startsWith('chrome-extension://') guard now catches them before any of that happens.

Tab profiler showing "unknown" for whitelisted, pinned, and audible tabs. The profiler was short-circuiting when the content script did not respond and leaving the status as unknown instead of falling through to the correct status calculation. Whitelisted, pinned, audible, and active tabs now show their correct labels.

What's next​

The feature/session-backup branch is the last major piece of TMS 9. The branch is public at feature/session-backup if you want to follow along with the commits, but read the warning below before you do anything else with it.

That changes with TMS 9.

This is the first in a series of posts we're calling Road to TMS 9, a chance to show you what's being built on the feature branches before it ships, explain the decisions behind the changes, and hear from you before things are set in stone. Think of it as development in the open.

Today: the visual redesign.

A design system from scratch​

The most important change in TMS 9's interface is one you won't immediately see: a proper design token system.

Rather than scattering raw hex values and px literals across a dozen CSS files (which is exactly how TMS looked until now), we wrote tokens.css, a single source of truth for every color, spacing step, type size, shadow, and animation duration in the extension. Every other stylesheet consumes these tokens. Change one token, the entire UI shifts consistently.

The color palette is built around OKLCH, a perceptually uniform color space that produces more predictable results across light and dark modes than the old rgb() / hex approach. The primary accent color is now the same cyan-blue used on marvellouscode.works, carrying the mascot's signature eye-glow right into the UI.

Light and dark mode are properly supported for the first time. The previous implementation layered hardcoded hex overrides inside body.dark { … } blocks, functional, but brittle. The token system drives both modes from the same cascade, and prefers-color-scheme is respected automatically. If you never touch the theme selector, the extension follows your OS.

One small but meaningful detail: @media (prefers-reduced-motion: reduce) sets all animation duration tokens to 0ms. If you've told your OS you want less motion, TMS will honor that.

New fonts​

TMS 9 ships two self-hosted variable fonts:

• Inter, the sans-serif workhorse for all body copy, labels, and form elements. No more system font lottery.
• JetBrains Mono, the monospace font used for version numbers, code-style strings, and button text. If you've used JetBrains IDEs or VS Code with this font, it'll feel right at home.

Both are loaded via @font-face with font-display: swap, so they don't block rendering. Both ship under the SIL Open Font License, along with Lucide, which replaces the old custom icon font.

Unified page identity​

Every settings page in TMS, Options, About, Health, Shortcuts, Sessions, now opens with the same brand header: Suspendy Guy on the left, the extension name in monospace bold, the Marvellous Codeworks logo anchored to the right. Sidebar navigation is now a proper <nav> element. Each content area gets an eyebrow label that anchors it visually before the content starts.

It sounds like a small thing. In practice it makes the extension feel like a coherent product rather than five loosely-related pages that happened to ship together.

Even the bare pages, Tab Health is a good example, got the full treatment. Same header, same sidebar, same typography system, even when there's almost nothing on the page yet.

The popup received the same treatment, a new brand bar at the top shows the mascot icon, the extension name, and the current version number. You always know what version you're running without opening the About page.

New features already on the branch​

The redesign commit wasn't just cosmetic. Two features worth knowing about landed alongside it.

Language override. TMS has always followed the browser's locale, if Chrome is set to Italian, TMS speaks Italian. TMS 9 adds a dropdown in General settings that lets you force a specific language regardless of what the browser reports. Useful if your browser is set to English but you'd rather read the extension in Italian (or vice versa). Implemented by fetching the chosen locale's messages.json at page load and using it in place of Chrome's i18n.getMessage().

Tab strip context menu (pending Chrome stable rollout). Chrome is adding support for "tab" as a context type in extension context menus, meaning TMS will be able to add entries to the right-click menu on the tab bar itself, not just on page content. The implementation is already live on the branch: Suspend/Unsuspend, Pause/Unpause, Never suspend domain, Never suspend URL, and the window/all-window variants. The Keyboard Shortcuts page already surfaces the note:

The catch is that Chrome hasn't shipped the tab strip UI yet (confirmed up to Chrome 149 at the time of writing). When it lands in stable, TMS 9 will support it automatically, no update needed on your end.

Under the hood​

The visual branch also includes some housekeeping that users won't see but that keeps the codebase healthy:

• All PNG images (except toolbar icons, which Chrome requires as PNG) have been converted to WebP, saving up to 77% in bundle size on some assets.
• The old custom Fontello icon font (6 glyphs, woff/woff2) has been replaced by a minimal Lucide SVG sprite, which is easier to maintain and extend.
• The Italian locale received a thorough overhaul: ~45 strings that were still in English have been translated, and several grammatical issues have been fixed.

The two main commits covering all of this are 1260f94 and b67f887 on the feature/visual-redesign branch, which is public if you want to follow along or try it yourself.

Next in the series​

The visual redesign is one piece of the TMS 9 puzzle. The next post covers something that might seem less exciting but is arguably more important: replacing the extension's aging third-party libraries, one abandoned since 2021, one stuck on a 2020 release candidate. We'll also have a question for the community about a feature that may or may not survive into TMS 9.

If you have thoughts on the redesign, what you like, what doesn't work, what you'd change, open a discussion on GitHub.

What happened​

Microsoft Edge is built on the Chromium engine, which means it inherits browser-level changes from the upstream Chromium project, including regressions. The change introduced around Chromium 149 that broke the tab group restore behavior for suspended tabs is now making its way into Edge builds.

As a result, Edge users are experiencing the same symptoms Chrome users saw earlier:

• Suspended tabs inside tab groups are silently discarded when the browser restarts.
• Tabs outside tab groups are not affected and restore correctly.
• The suspended tab URL (chrome-extension://… / extension://…) is apparently filtered out during session restore when inside a group.

This is tracked in the dedicated GitHub issue #374, opened specifically for Edge. Issue #369, the original Chrome report, has also been reopened because of these lingering effects across the Chromium ecosystem.

Current status​

To be clear about where things stand right now:

• The browser-side Chromium fix is under review but has not yet landed in Chrome's stable channel, Chrome 149.0.7827.156 is still affected. The fix is expected sometime this weekend or early next week.
• Edge will take even longer, as it follows its own release schedule on top of Chromium's.
• TMS 8.1.4 addressed the issue for Chrome users at the extension level, but some edge cases are still being investigated (see #369).
• TMS 8.1.5 is in active development and specifically targets the Edge regression. A fix has already been tested and looks solid, we expect a release candidate to be ready very soon.

We are not waiting for the browser vendors to ship their fix. We are shipping our own.

Temporary workaround​

If you lost tabs, the manual recovery steps still apply:

1. Open the tab group that now shows blank New Tab pages.
2. For each empty tab, click the browser Back button (top-left arrow) once.
3. The original suspended tab page should reappear.

What we are doing about it​

• TMS 8.1.5 is coming, with a targeted fix for Edge. Follow PR #376 for progress.
• We are tracking the Edge-specific report in issue #374, follow it for real-time updates.
• Issue #369 has been reopened to track lingering issues for Chrome users on TMS 8.1.4 as well.
• The upstream Chromium fix (chromium-review.googlesource.com) will eventually reach Edge too, but we are not relying on that timeline.

We know how frustrating this is, especially after Chrome users already went through it. Thank you for your patience.

References / Links​

• TMS & Chrome 149: the original post
• GitHub issue #374 – Edge-specific tab group regression
• GitHub issue #369 – Original Chrome 149 report (reopened)
• PR #376 – TMS 8.1.5 Edge fix
• https://chromium-review.googlesource.com/c/chromium/src/+/7933990

What's fixed​

Suspended tabs inside tab groups restored correctly after restart​

Starting with Chrome 149, a change in the browser's session restore engine caused tabs with non-https:// URLs, including TMS suspended tabs, to be skipped when restoring tab groups. This resulted in blank New Tab pages appearing in place of your suspended tabs after every restart.

TMS 8.1.4 works around the Chrome-side behavior and restores suspended tabs inside tab groups correctly again. Tabs outside tab groups were not affected and continue to work as before.

Full changelog on GitHub: v8.1.4 release

Related: TMS & Chrome 149: suspended tabs inside tab groups lost after restart

If you are using Chrome 149 and noticed that your suspended tabs inside tab groups turn into blank New Tab pages after a browser restart, you are not alone, and it is not your fault.

What happened​

Starting from Chrome 149, a change in the browser's tab group restore engine broke compatibility with suspended tabs managed by TMS. When Chrome restores a session after a restart, it now skips tabs whose URL does not start with https:// inside tab groups. Since TMS suspended tabs use an internal chrome-extension://… URL, they are silently discarded instead of being restored.

Tabs outside tab groups are not affected and restore correctly as before.

The issue was reported by users shortly after Chrome 149 rolled out and confirmed by the TMS team. A member of the Chrome development team has acknowledged the problem and filed an internal bug to investigate whether the behavior change was intentional or an unintended side effect.

Temporary workaround​

If you lost tabs, there is a way to recover them without restoring a backup:

1. Open the tab group that now shows blank New Tab pages.
2. For each empty tab, click the browser Back button (top-left arrow) once.
3. The original suspended tab page should reappear.

This is tedious if you have many tabs, but it beats losing them permanently.

What we are doing about it​

• TMS 8.1.4 is now available on the Chrome Web Store. It addresses the tab group restore issue directly, suspended tabs inside tab groups will no longer be discarded after a browser restart. Update TMS and the problem goes away.
• The Chrome team also had an official fix under review on the browser side; TMS shipped the fix first.

We know how frustrating data loss is, and we are sorry you hit this. Thank you for your patience while we sort it out.

Companion workaround: back-grouped-tabs​

While the proper fix was in the works, a small companion extension was made available: back-grouped-tabs.

It does one thing: when Chrome restores a session and discards suspended tabs inside tab groups, this extension detects the affected tabs and navigates them back so the suspended page reappears, automatically, without you having to click the Back button on each one.

To install it, clone or download the repository and load it as an unpacked extension in Chrome (chrome://extensions/ → enable Developer Mode → Load unpacked). The README covers everything you need to know.

References / Links​

• https://chromium-review.googlesource.com/c/chromium/src/+/7933990
• https://chromium-review.googlesource.com/c/chromium/src/+/7738373

Follow the original issue on GitHub: #369 – Suspended tabs inside tab groups are lost after browser restart (Chrome 149)

But five years later, TMS isn't a patched-up copy of someone else's abandoned code anymore. It's had a full Manifest V3 rewrite, a proper visual redesign, its own contributors, and, as of a few months ago, a home under the Marvellous Codeworks name. The GitHub fork relationship, though, hadn't changed: technically, gioxx/MarvellousSuspender was still listed as a fork of the original repository, tied to its network, its issues, its history.

Asking GitHub to cut the thread​

So I asked GitHub Support to detach it, a "Detach/Extract Fork" request, which pulls a repository (and its own child forks) out of the network it was born in and gives it a clean, independent history on GitHub's side. No more fork badge, no more shared network with the original project.

GitHub got back to me quickly:

I have gone ahead to extract that fork for you. The repository gioxx/MarvellousSuspender and its child forks are now in a new network.

Done. As of today, TMS no longer carries GitHub's official "forked from" label.

Why it matters​

This isn't a cosmetic change, and it isn't really about the label either. It's the first concrete, official move to stop treating TMS as an offshoot of something else and start treating it as what it actually is: a project with its own direction, maintained by Marvellous Codeworks.

It also isn't the last step. Right now gioxx/MarvellousSuspender still lives under my personal GitHub account. The plan is to move it, along with the rest of what makes up TMS, under the Marvellous Codeworks organization on GitHub, where other projects already live. We're aiming to get that done by the end of summer 2026.

Small steps, but each one makes it a little more true: TMS's future isn't tied to what it was forked from anymore. It's Marvellous Codeworks now.

What's fixed​

Vivaldi getContexts workaround​

Vivaldi implements a non-standard version of the chrome.runtime.getContexts API that was causing TMS to throw an unhandled error. This release adds a workaround that detects and handles the inconsistency, restoring normal operation for Vivaldi users.

Special thanks to @wobondar for supporting the project! ❤️

Full changelog on GitHub: v8.1.3 release

What's new and fixed​

Session export filename includes the date​

When you export your session from the Session Management page, the downloaded file now includes the current date in its name. This makes it much easier to keep track of multiple backups without manually renaming files.

Suspended tab version watermark​

The suspended tab page now displays the TMS version number as a subtle watermark. This small addition makes it easier to identify which version was running when users share screenshots in bug reports.

Update banner is now clickable​

The "a new version is available" notification banner is now interactive, clicking it takes you directly to the release page instead of requiring you to navigate there manually.

Session page scroll fix​

Links within the Session Management page no longer cause the page to jump back to the top when clicked.

Whitelist test button refactored​

The "Test whitelist" function has been cleaned up internally for more reliable pattern matching.

Other changes​

• Localization updates via Crowdin
• Dependency bump: js-yaml patched for a security advisory

Full changelog on GitHub: v8.1.2 release