Release safety

Manifest V3 testing checklist before you publish.

A useful MV3 regression pass covers more than the popup. It checks the built package, host-page behavior, extension pages, permissions, storage, and what happens after the background service worker disappears and starts again.

Last reviewed August 18, 2026 · Based on current official Chrome extension guidance.

1. Inspect the exact build you will ship

• Load the packaged or unpacked release build, not a development server with different permissions or code paths.
• Confirm manifest_version, version, icons, popup/options paths, content-script matches, service-worker path, and minimum browser version.
• Review requested permissions and host permissions. Test both the granted and denied states when the extension can operate with optional access.
• Open the Extensions page and resolve every manifest or runtime error before starting user-journey tests.

2. Start from an isolated browser profile

• Use a fresh profile or temporary user-data directory so an old installation, cache, or storage value cannot hide a first-run defect.
• Use synthetic accounts and fixtures. Block purchases, destructive API calls, and production credentials.
• Run one upgrade test separately: install the previous release, create representative state, then load the new build and verify migration behavior.

3. Test each user-visible surface

4. Force the MV3 lifecycle failure

Chrome normally terminates an extension service worker after a period of inactivity. A passing warm test can therefore hide missing initialization or reliance on module-level variables. Stop the worker from the Extensions or DevTools interface, then perform the next critical user action without manually waking it first.

• Register event listeners synchronously at the top level.
• Persist important state instead of treating globals as durable.
• Use alarms or another supported event source for durable scheduling; do not rely on a long-running timer.
• Verify that interrupted work fails safely and can be retried.

Official reference: Chrome’s extension service-worker lifecycle.

5. Exercise failure and recovery paths

• Offline or slow network, expired authentication, rejected permissions, missing active tab, and closed popup.
• Host page navigation, iframe or Shadow DOM boundaries, and a content script that arrives later than expected.
• Repeated clicks and messages: the same action should not create duplicate records or duplicate injected UI.
• Browser restart and extension update with existing user data.

6. Keep evidence that explains the first divergence

For each critical journey, capture the first failing step, the visible state, relevant console output, network result, current URL/surface, and service-worker state. Evidence should use synthetic data and avoid secrets. A screenshot alone is often insufficient when the failure is caused by a worker restart or message boundary.

7. Define the release gate

• All critical journeys pass in a clean profile.
• The service-worker cold-start check passes.
• No unexpected permission, manifest, or console error remains.
• Upgrade behavior and deletion/reset behavior are verified.
• Any skipped case has an owner and a written risk decision.

For implementation details, continue with testing a Chrome extension with Playwright and the service-worker restart test.