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

What's fixed​

Update banner false positives​

An issue introduced in 8.1.0 caused TMS to show the "a newer version is available" notification even when the extension had already been updated to the latest version. This has been resolved: the banner now correctly compares the installed version against the latest release and only appears when an actual update is available.

Other changes​

• Additional internal fixes found during the update-detection review
• Updated package dependencies and ESLint rules

Full changelog on GitHub: v8.1.1 release

What's new​

Tab Group support​

TMS will now save and restore your Tab Groups across version upgrades and session save/restore operations. Groups are preserved with their names and colors. This was the most requested feature since the MV3 rewrite.

Automatic theme​

A new System option has been added to the theme selector in Settings → General. When selected, the suspended tab page follows your operating system's light/dark preference automatically. The existing Light and Dark options remain.

More suspend intervals​

The "Suspend automatically after" dropdown now includes additional minute-level options, giving more fine-grained control over how quickly inactive tabs are suspended.

Favicon reliability​

Several improvements to favicon fetching and caching make the icon shown on suspended tab pages more consistent, especially in Chromium-based browsers like Vivaldi.

Session Manager shortcut​

A dedicated quick-access button to the Session Management page has been added to the extension popup, so you can reach your saved sessions without opening the full settings.

Other fixes and changes​

• Removed cookies permission (no longer needed)
• Fixed TypeError: undefined crash in tab queue handling
• Removed leftover console.log from the content script
• Added extension icon images to web_accessible_resources for Vivaldi compatibility
• Various Crowdin localization updates

Full changelog on GitHub: v8.1.0 release

What's changed​

Manifest V3 migration​

The entire background processing layer has been rewritten as a service worker (background.js), replacing the persistent background page required by Manifest V2. This brings TMS in line with Google's current extension requirements and ensures continued availability on the Chrome Web Store.

New and changed permissions​

The permission set has been updated to match what Manifest V3 requires and allows:

The cookies permission has been removed (scroll position migration from older versions is no longer needed).

Other improvements​

• Sanity checks added across tab logic to handle edge cases more gracefully
• Tab group data is now included in session recovery storage
• SVG page fix: document.body is no longer accessed on SVG tabs, preventing a TypeError
• Various localization updates via Crowdin

Minimum Chrome version​

TMS 8.x requires Chrome 110 or later.

Full changelog on GitHub: 8.0.0.0 release

Had I lost hope? I'll admit it, yeah, pretty much completely. So you can imagine how thrilled I was when I finally saw a light at the end of that tunnel.

Rob is the guy behind The Great-er Tab Discarder, itself a fork of an older, seemingly abandoned project, another extension born out of the need to fix a gap that often makes Chrome unusable in the long run (especially when you're juggling hundreds of open tabs). When Rob took an interest in TMS and decided to take on the challenge of making it compatible with the more limited Manifest V3, I saw an opportunity. I reached out to him, and together with a third person from Google, we kicked off a group chat to start connecting the dots and try to make the leap.

The result? It's publicly available here: github.com/gioxx/MarvellousSuspender/pull/253 (now merged with the original repository), a pull request that includes a pretty much rewritten version of TMS for Manifest V3. A 1:1 migration of what's under the hood in the current TMS just isn't possible.

What we need now is a pool of users willing to test this new version of TMS, help us figure out what's still missing, what kinds of issues might come up across different environments, systems, and setups, and what needs to be fixed right away before we publish it on the Chrome Web Store. Only then can we reach all users again and start the (long) journey toward improvements and new features, aiming to finally hit full feature parity, something we're still missing today.

A few quick but essential tips before taking the leap. If you're thinking of joining the testing community for the new version of TMS, I strongly recommend you:

• Save the current state of your open tabs in Chrome.
  TMS (the version currently available) lets you create a full backup, which you can export and keep safe.
• Wake up all your tabs (or pick and choose which ones you want to keep active in the browser, you can always reopen the others later). Try to streamline things as much as you can, so the transition to the new version of TMS is smoother.
• Install the new version of TMS.
  Clone the repo to your PC (or download the full ZIP and extract it), enable Developer Mode in Chrome (chrome://extensions/), then hit the Load unpacked button and select the folder where you saved the files from the repo. You have to load only the src subfolder. At that point, you'll be running the new version of TMS, compatible with Google's Manifest V3, and it'll be back to managing your tabs like before.

What you'll see looks familiar, same interface you're used to, nothing seems to have changed. But under the hood, it's a whole different engine.

Just a quick reminder: using the Load unpacked option won't overwrite your current TMS installation. Chrome treats the new Manifest V3-compatible version as a completely separate extension, so there's no need to uninstall your current TMS, both versions can run side by side.

That's why we suggest:

• Keep your current TMS installed, but set the automatic suspension to Never.
• Set up the new version to handle tab suspension.

This way, you'll be able, if you want, to wake up your older tabs and suspend them again using the new version.

Thanks a ton to everyone willing to test, break things, and share thoughts, this kind of support is what keeps open source alive and kicking.