Manifest V3: Debugging Extension Service worker is a pain

[Wagner Moreira]

Hi Folks!

I'm having a super hard time to debug my service worker (background script) in my chrome extensions v3

The problem is, when I have dev tools open the service worker will NEVER go inactive, and what I'm trying to do is identify when the SW wake up to perform tasks, super duper weird because I need devtools open to debug...

how do you debug an extension SW without devtools open?

[Cuyler Stuwe]

If you’re just trying to identify when it wakes up to do things, I would have another component listening for messages, and have SW send it a message literally every time it takes up to do anything at all.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/cec5ef1a-34d0-4f08-9ef1-db61b8c1d561n%40chromium.org.

[Zenitsu]

thanks for your reply! because the file is a service worker I don't think I can have a component there, and my use case is to not reply on a popup or a content script to do the service-worker tasks
what I'm trying to do is the following

In my extension background.js (service worker) I want to do this:
- connect to WebSocket to get data updates
- reconnect to the Websocket when service-worker wake up

- I need to do these tasks while not relying on having a port open with the popup or a content script
- those are tasks to get data updates from a WebSocket and update the badge text and send notifications.

note: I'm using Chrome Alarms to wake up the service worker

it may sound weird that I have to reconnect every time the service worker wakes up considering chrome is shutting the service worker down like every 15s or less once I close the extensions dev tools (which makes me cry blood)
but it is better than sending xhr periodically using Chrome alarms, which would result in a lot more requests being sent to an API, so reconnecting to the websocket

do you/anyone reading this have any recommendations/thoughts?

[wOxxOm]

Here's an alternative method of debugging SW, which may seem unwieldy at first, but once you try and get the knack of it, it's quite trivial and even can beat devtools that's shown when clicking the "service worker" link in chrome://extensions page because this one a) shows extension's localStorage in devtools, b) provides control over service worker lifetime/execution, c) supports performance profiling (bug 1229555).

1. open any visible page of the extension or, if there are none, its manifest.json URL like chrome-extension://*id*/manifest.json
2. switch to the Application tab, then choose `Service worker` in the left panel
3. click `start` (if shown) to start the service worker, click the script name to open it in the Sources panel, set breakpoints, etc.
4. click `stop` to stop the service worker, optionally click `Update` at the top, and `skip waiting` in the middle (if shown) to force an update
5. click `start` again - your breakpoints will trigger.

When the service worker is started you can see its context in the Sources panel on the left (in the files panel), on the top-right (in the threads panel), in the console toolbar (the context selector).

[Zenitsu]

thanks so much that's super useful! 

another thing I'm trying to figure out is, is it possible to use Web Push API https://github.com/mdn/serviceworker-cookbook/tree/master/push-simple

with a chrome extension? I can't wrap my head on how to use it with a chrome extension

[Yuan Ho]

May I ask how to switch to the Application tab in the chrome-extension://id/manifest.json page? Thanks.

[wOxxOm]

> how to switch to the Application tab

1b. open devtools