Debugging Service Workers in Firefox: DevTools, about:debugging, and Common Issues

Service workers are a critical web platform feature — they enable offline capabilities, push notifications, and background sync. Firefox has full service worker support. Here's how to work with them in Firefox DevTools.

What Service Workers Do

A service worker is a JavaScript file that runs in the background, separate from the page. It can:

• Intercept network requests and serve cached responses (offline support)
• Handle push notifications
• Perform background sync
• Pre-cache assets

The service worker lifecycle: Registration → Installation → Activation → Fetch interception.

Firefox Service Worker Debugging

about:debugging

Navigate to about:debugging#/runtime/this-firefox (or about:debugging → This Firefox).

The Service Workers section shows:

• All registered service workers
• Their scope (which URLs they control)
• Status (running, stopped, waiting to activate)
• Buttons: Inspect, Push notification test, Unregister

Click "Inspect" to open the service worker's DevTools — a separate DevTools window for the worker's context, with its own Console, Debugger, and Network panels.

DevTools Application Panel

Firefox DevTools → Application tab (if not visible: toggle in "…" menu).

Shows:

• Manifest: Web App Manifest if present
• Service Workers: Registered workers, their state, and registration details
• Storage: Cache Storage, IndexedDB, Local Storage per origin

Under Service Workers, you can:

• See if a worker is active
• Force update/unregister from the panel
• Send a test push notification
• Enable "Bypass service worker" mode (forces network requests to bypass the cache)

Debugging Fetch Interception

In the service worker Inspect window → Network tab.

Shows all network requests intercepted by the service worker. You can see:

• Which requests were served from cache
• Which went to network
• Response headers and status

Useful for diagnosing "why is my app showing stale content?" — the Network tab in the worker shows the fetch handler decision.

Console in Service Worker Context

In the page's regular Console, messages from the service worker appear with a "[Service Worker]" prefix.

For the worker's own Console (separate window via Inspect), you can execute code in the service worker's context — check cache contents, force cache updates, test logic.

// In service worker console:
caches.keys().then(keys => console.log('Caches:', keys));
caches.open('v1').then(cache => cache.keys().then(k => console.log('Cache contents:', k)));

Debugging the Installation Phase

A common issue: service worker isn't activating because a previous version is stuck.

In about:debugging or the Application panel:

1. Check if there's a "Waiting" service worker
2. A waiting SW means: there's an active SW controlling pages, and the new version installed but can't activate until all pages using the old version are closed
3. For development: click "skipWaiting" button (if you added self.skipWaiting()) or use "Unregister" + reload

Enabling "Update on reload" in DevTools:
Application panel → Service Workers → Check "Update on reload"

This forces the service worker to update on every page reload — essential during development to avoid stale cached worker code.

Common Service Worker Issues in Firefox

Issue: Service worker installs but isn't intercepting requests.

• Check scope: the service worker only controls pages under its scope URL
• Verify registration: navigator.serviceWorker.getRegistrations().then(r => console.log(r))

Issue: HTTPS required.
Service workers require HTTPS (or localhost). Firefox enforces this — no SW registration on HTTP pages in production.

Issue: Cached responses not updating.
Use cache versioning. In the service worker:

const CACHE_VERSION = 'v2'; // Increment to bust cache
self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(keys => 
      Promise.all(keys.filter(k => k !== CACHE_VERSION).map(k => caches.delete(k)))
    )
  );
});

Issue: Service worker registered but shows "stopped" in about:debugging.
Normal — Firefox stops idle service workers to save memory. The worker activates on demand when a fetch occurs.

Testing Offline Behavior

Application panel → Service Workers → Check "Offline"

This simulates offline mode (service worker handles all requests; no network available). Good for testing your PWA's offline fallback behavior.

You can also throttle network in Network panel → Performance tab for slower-than-offline testing.

Background Sync and Push Notifications

Firefox supports:

• Background Sync API: Registered sync events fire when the browser has connectivity
• Push API: Firefox has a push server (different from Chrome's FCM)

For push notifications on Firefox: use the Web Push protocol (standard). Firefox doesn't require Google Play Services (unlike Chrome on Android) — Firefox for Android uses its own push server.

about:debugging → Service Workers → "Push" button sends a test push event to the worker without a real push server.

Workbox (Service Worker Library)

Most production service workers are generated via Workbox (Google's SW library). Workbox-generated workers work correctly in Firefox.

To debug a Workbox worker: the Inspect console will show Workbox's log output. Enable verbose logging:

// In your Workbox config:
workbox.setConfig({ debug: true });

Or via about:config → toolkit.telemetry.debugSlowSql — no, that's not right.

Actually: Workbox respects the devtools setting. Run workbox.core.setLogLevel(workbox.core.LOG_LEVELS.debug) in the service worker console.

Firefox's service worker tooling is mature and covers all the debugging scenarios you'll encounter in production PWA development.