Helping test a fix before it ships
Sometimes, while a bug is being investigated, a maintainer shares a test build (a .zip), attached directly to the GitHub issue or published as a GitHub pre-release linked from it, and asks people affected by it to try it before the fix ships in a real release. This page covers that workflow in general, see issue #437 for a real example of how one of these threads plays out end to end.
Testing is entirely optional and always welcome, more real-world runs on a fix before it ships means fewer surprises for everyone once it does.
Before you install it
It's the same extension ID as the Store version. A test build replaces your currently installed TMS and shares its local data, it cannot run side by side with the Store version. Loading it is what actually starts the test, there's no separate "try without installing" option.
- If you already have Sync settings across devices and/or automatic session backup enabled, you're already covered, both survive the switch either way.
- Otherwise, as a safety net before installing: export your settings (Settings → export) and save your current sessions as JSON (Session Manager → save/export).
Installing the test build
- Download the
.zipthe maintainer linked on the issue and extract it to a folder you will keep: the browser keeps loading the extension from there, so don't delete or move it while testing. - In Chrome (or Brave/Vivaldi/Edge), go to
chrome://extensions/and enable Developer mode. - Click Load unpacked extension… and select the folder that contains
manifest.json. In current test builds that's the extracted folder itself; older ones had it inside asrcsubfolder.
This replaces your current installation. See Install from source for more detail on this general mechanic if anything looks unfamiliar.
Check the version shown on the extension's card in chrome://extensions/. Test builds carry a label naming the issue they are for, for example 9.1.0-test.523, so you (and the maintainer reading your report) can tell them apart from a Store release. Older test builds kept the last release's version number instead. Either way, a test build isn't a new release on its own, just the fix layered on top for testing purposes.
What to test
Follow whatever specific steps the maintainer asked for on the issue, they vary per fix. As a general shape: try to reproduce the exact problem you originally reported, the way you'd normally hit it (not just once, artificially), and report back whether it still happens.
If the fix is timing- or condition-dependent (a backup reconnecting after some hours, a crash needing many tabs), a longer, more realistic test run is far more useful than a quick artificial one, say so either way when you report back.
If something looks off
Open the Diagnostic page, enable captureLogs, reproduce the issue, then use Copy report or Download report. This bundles your TMS version, browser details, and recent logs into one shareable block, far more useful to a maintainer than a description alone. It can also include tab titles/URLs, so upload it to logdrop instead of pasting it into the issue thread, only the maintainer can read it, and it expires on its own.
Going back to the Store version afterward
Once the fix has shipped for real (or if you'd rather stop testing), remove the local build from chrome://extensions/ and install the Chrome Web Store version again.
Removing an extension makes its suspended tabs disappear permanently. Right before removing the local build, export your current session again (Session Manager → export) or unsuspend all tabs, so you can bring them back after reinstalling.
- If you have Drive backup or settings sync enabled, sign back in and your data restores from there.
- Otherwise, import the session file you exported before installing (Session Manager → import), or restore from a local backup file if automatic backup was on.
Removing the local build first and installing from the Store after is what keeps you on automatic Store updates going forward, installing over the top the other way around does not.