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:
- Check if there's a "Waiting" service worker
- 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
- 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.#webdev #firefox #javascript #pwa #software #coding #development #engineering #inclusive #community
Debugging Service Workers in Firefox: DevTools, about:debugging, and Common Issues
