bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Service worker script fetches do not show up in the network monitor




Developer Tools: Netmonitor
2 years ago
6 months ago


(Reporter: Ehsan, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [swdev-m1])


(3 attachments)



2 years ago

Go to https://serviceworke.rs/json-cache_demo.html. A "service-worker.js" entry doesn't show up in the network monitor.

I'm not sure why this might be, but my hunch is that the information we use to associate the network connections made in tab A versus tab B may be incorrect somehow...
Thanks for the report!

I am setting P2 since nobody is having this on the TODO list atm, but sounds important to me to be fixed.

Severity: normal → enhancement
Has STR: --- → yes
Priority: -- → P2
This is kind of that same as bug 1246289, but maybe a bit different.

Note, we also don't show any network requests for fetches initiated from within the service worker.

We probably need to attach the service worker ID to the nsIChannel somehow and then devtools can use nsIServiceWorkerManager:ShouldReportToWindow() to determine if the toolbox should show that channel.
Blocks: 1262699
See Also: → bug 1246289
(In reply to Ben Kelly [:bkelly] from comment #2)
> Note, we also don't show any network requests for fetches initiated from
> within the service worker.

This particular part has been fixed.  We still don't show the service worker script load itself, though.  (And probably not importScripts() either.)
Whiteboard: [swdev-m1]


a year ago
Assignee: nobody → bhsu

Comment 4

a year ago
Created attachment 8850384 [details]


a year ago
Duplicate of this bug: 1246289

Comment 6

a year ago
Created attachment 8852022 [details] [diff] [review]
P1: Use aLoadGroup instead of creating a new one

Comment 7

a year ago
Created attachment 8852023 [details] [diff] [review]
P2: Add a chrome mochitest

Comment 8

a year ago
Flags: needinfo?(bkelly)
Comment on attachment 8852022 [details] [diff] [review]
P1: Use aLoadGroup instead of creating a new one

Review of attachment 8852022 [details] [diff] [review]:

r=me because this is an improvement, but I think we may want to some follow-on fixes.  For example, I don't think this will show importScripts() or background update requests in the network monitor.  It will only show requests triggered from a .register() call.

We may need some server worker specific code in devtools to understand a SW loadgroup and call ServiceWorkerManager::ShouldReportToWindow() to figure out if it should be displayed in a particular network monitor:


::: dom/workers/ServiceWorkerScriptCache.cpp
@@ +655,4 @@
>                       uri, aPrincipal,
>                       nsILoadInfo::SEC_REQUIRE_SAME_ORIGIN_DATA_IS_BLOCKED,
>                       nsIContentPolicy::TYPE_INTERNAL_SERVICE_WORKER,
> +                     aLoadGroup,

Just for my own clarification, this is safe to do because we are not actually passing the document's load group.  Instead we actually have a separate loadgroup that also happens to point at the document's loadgroup's notification callbacks:


So if the window is closed the registration load won't be canceled.

I don't think this will help report service worker script loads for update() calls or automatic updates.  In those cases we pass nullptr for the load group:


Also, I don't think this change will report network channels for importScripts() loads.
Attachment #8852022 - Flags: review+
Flags: needinfo?(bkelly)
This seems depends on SW redesign clientId support as well ...
Priority: P2 → P3


6 months ago
Assignee: bhsu → nobody
You need to log in before you can comment on or make changes to this bug.